Setting an explicit SVG viewbox

Thanks for your thoughtful feedback and workaround suggestions.

Just to bring it back to the original question, which I gather is just not possible in Figma at the moment: how does one restrict the viewbox on an exported SVG without clipping. As I suggested, this is possible to do in other vector graphics software, such as Illustrator, and Affinity Designer.

I really love Figma and I don’t want to spend any time in other tools if I don’t have to. Lets consider this a Figma feature request!

I have a similar problem. When exporting icons. My component icons are 24x24. I use them in design at 50x50. And they look and measure exactly 50x50. But when I export this 50x50 instance it adds 1px to some time to the width or height. Its very random. I am not able to get where this 1px adds to height while export

Exactly same problem here. What is the fix so that I don’t have to edit manually all the svgs of my icons to be rectangular?

Sadly I found no fix, other than to do what you said: make sure all the vector graphics are fully contained within a frame that is the exact export size you want.

This does not solve the use case I mentioned, where graphics need to extend outside the viewbox. For that, the only “solution” it seems is to use Illustrator 🙃.

I understand your point perfectly Andrew, and I’d like to do the same. Restricting an objects viewbox would help a lot to fit that object within grids in design and code even though it’s “visual” exceeds the area it occupies. I’m very insterested in being able to do this in Figma.

Content extending beyond the bounds of the view box is totally valid. Icons are typography; this is roughly analogous to glyph kerning or optical corrections overlapping the baseline.

Additionally, effects like shadows cause the view-box to change unpredictably upon export. This is not great.

Definitely would be valuable to have an export option to “expand to include content”.

Did you ever find a solution to the viewbox issue? I’m trying to do something similar. As a dev, I sometimes like to animate elements of the svg using CSS transforms. It’s much easier to do so if the element is “centered” at the 0,0 point, which means that some of it will be outside of the viewbox.

Hey, this is a year old, I’m realising. As far as I know, it is not possible for SVG to show stuff that exceeds the viewbox. Also SVG doen’t support strokes that are set to “inside” or “outside”. So essentially this is a SVG restriction, not necessarily a Figma restriction.

If your frame is positioned at the X or Y axis with a decimal (like X:65.88 instead of 66), Figma will try to compensate with the extra pixel when it exports the SVG. It is the same behaviour I encountered in Adobe Illustrator. So just make sure all your frames are positioned properly on both X & Y axis

Hope this helps.

Hello all! As of writing it's been 5 years, 19 replies and >21,000 views since the original post here and unfortunately, as far as I know, there are still no native workarounds or even plugins getting around this quite just yet.

There seems to be a lot of confusion in this thread here, so I want to reiterate what's actually going on. See this Codepen for a quick demonstration and also how you can work around it, or just look at the screenshots and description below:
 

When you have some geometry in a container as shown on the left, when you export that container as an SVG, Figma first starts with the dimensions of your container, and then it grows each side out to completely contain any geometry overflowing that container. This makes sense for other formats, but SVG actually works completely differently and makes this "growing" behavior unexpected. As described by MDN and also W3, see https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/overflow and https://www.w3.org/TR/SVG2/render.html, SVGs are mathematically infinite 2d planes extending in all directions from the root, and by definition support geometry outside of the viewBox bounds and the SVG tag's bounds, including rendering such geometry outside the SVG container’s bounds, see Section 3.11 of the W3 SVG2 standard describing the effect of the 'overflow' property. TLDR, Assuming you disable clipping, SVGs are naturally capable of displaying overflowing content, which can be imperative to many layout use-cases as described in this thread.

Fixing this is as simple as just not expanding the coordinate space or the bounds, and then just flattening and converting the points to SVG instructions just the same as before. I would love to see this capability introduced even as a simple checkbox nested right here:

, however, this could also just be set as the default behavior as I personally think it makes much more sense. One can always simply select another layer down for the other behavior, or just have this one toggleable but on by default.

Until then, one workaround is to take this expanded export, and then change the container’s width/height to match your expected, and then apply an offset to the path tag to repair the alignment. This is very clumsy though and doesn’t scale well at all.

Little did we know though, the functionality that would fix this already completely exists! Its actually an existing export API flag, useAbsoluteBounds: true, only this option has not been exposed to us as a checkbox or anything as far as I know for some reason. When enabled, this flag makes exports behave exactly as you are expecting, setting the exported SVG's viewBox and width/height to that of the selected root container, while also still preserving any geometry extending outside of said container.

I used Claude to make a simple wrapper for this API endpoint with a single button and the useAbsoluteBounds flag enabled and published it. It's still under review at the time I am posting this, but here is the link, its called Boundless SVG, feel free to use it until they hopefully add this to the default interface https://www.figma.com/community/plugin/1661087742930466062. I’ll make a github repo and post the source code too when I get around to it, I’ll just link it in the plugin page. It was only about 300 lines, and that's mostly just html, again the actual functionality was just a single flag, see it highlighted below.