FIXED: SVG exports at a different size to W & H values in editor

Look at the coordinates of this object. The coordinates should be integers, with no fractions.

Good eye! I did this and I got 61x61 🤷‍♀️ At least it’s a consistent ratio, thanks 👍

Hmm that sounds weird. If this object is nested in another frame, make sure that frame is on integer coordinates as well.

Oh no! I did that and it went back to exporting at 60x61 again!

Are there any more nested frames? Just put this frame you are exporting directly to canvas and send it to 0x0, this will definitely do it. And turn pixel grid snapping on in preferences. How do you even get things to such weird positions? 😃

Bam! That worked! Thanks!

This work involved a bunch of custom components outside of our system + illustrations so somewhere along the line a little too much freeform expressionism got in here 🙂

Good to know that the position of a parent element can effect the exported properties of object. This is news to me.

Any idea why that doesn’t get reflected in the editor’s W & H values?

The main problem that can cause export cropping issues is if you have the object on non-integer absolute coordinate or if the object has non-integer scale (with fractions). Absolute means all frames it is nested in should be at integer coordinates too. Or you can align it to the absolute pixel grid ignoring underlying frames, but I think the former is simpler.

You can also check if the object is aligned to pixels by using File → Export… If the object is not aligned to pixels, it will show Origin not aligned to pixel error. Note that sub-pixel size will not trigger this error while still causing the issue with white stripes on the sides.

That’s because export works slightly differently than what is displayed in Figma. It’s a bit easier to explain with raster images but the similar logic applies to SVG export too. Let’s say you have a 10x10 image at 0.5 coordinate. Subpixels will be turned into full pixels and since the image starts on pixel 0 and ends on the 11th (10.5), it will be exported with width/height of 11 pixels. This obviously is not the case for SVG since it can take absolute values but I guess it calculates the bounding box this way. Maybe because SVG can contain raster images.

What if I’m exporting not in 1x?

Even if coordinates you set aren’t sub-pixel in 1:1 export, they can be when exporting in different sizes. Let’s say you are exporting a node in 1.5x for example. Technically, the whole canvas would be enlarged to 1.5 to export this piece at this resolution. This would result in fractional numbers in coordinates. If your frame is standing on coordinates (3, 11), then the result will be at coordinates (4.5, 16.5). I don’t know why it works this way but it does. So to ensure your export at 2.4x works correctly, the object needs to be standing on coordinates divisible by 5 (because 0.4 is 2/5). Alternatively you can set the export dimensions explicitly (e.g. 900w as 375*2.4=900), this way the canvas shouldn’t multiply this way and the coordinates can be any integers.

That makes sense, appreciate you taking the time to break it down 🙏

This issue was driving me crazy - thanks for explaining.

Example:
If “align to pixel grid” is not enabled, any element is vulnerable to being exported at the wrong size, with a white border added.

But with “align to pixel grid” enabled, simply drag the element anywhere and it will then export correctly.

@Gleb a big “Thank You”. I also had the same issue while exporting PNGs and JPGs. My problem was that in the Width and Height displayed as 120 × 120. As I took a closer look at the rulers on the canvas, it said that my pixel dimensions have been 120 × 120.001. So, it was wrong on third place after the comma.

During the day, I was trying to figure out what happened with my illustration library. In Figma everything was pixel-perfect, on GitHub… not really. At the end of day I figured out this issue, and I can reproduce it, I was so happy about that. Finally an issue and I can solve it. But… this issue is still existing since March. Time to fix it. 😃

If somebody works with illustrations or maintains huge libraries, we need to turn off pixel grid.