Let’s say we draw the same vector graphic in different design applications and export each one as SVG for use on the web. Should we expect the same SVG file from each application?
On the one hand, we might expect each file to be the same because of our past history with exporting images. Applications have typically been consistent at saving JPGs, PNGs, and GIFs with perhaps minor differences to the overall file size.
On the other hand, SVG is different than our typical image file and our expectations might need to adapt to those differences. The output of SVG might be visual, but what we’re really talking about is math and code. That means an SVG file is a little more comparable to a CSS file that has been compiled from a preprocessor. Your results may vary based on the method used to compile the code.
I decided to draw the same illustration in Illustrator, Sketch, and Figma and compare exported SVG code. This post will summarize those results.
About the Illustration
It’s nothing fancy. A basic plus sign with a white fill on top of a circle with a black fill. The idea was to use something that’s close to an icon that would be common on any site.

The illustration was drawn three times, once in each application. Making the icon in one application then copying and pasting it in another didn’t seem like a fair comparison. This allowed each application to interpret the SVG from its own native tools. I’m not the most skilled illustrator, so I made the illustration once, then traced it in the other applications to ensure everything was to scale and that all the points were nearly identical.
About the Comparison
It’s worth noting that this post is not at all concerned about the “best” export of the group. What’s more interesting is (1) whether there are differences in how SVG code is compiled and (2) how those possible difference might affect a front-end workflow or even influence which application is better suited for a particular project.
Here’s what is being compared:
- File Size
- Code Structure
- Naming Standards
One more thing with mentioning is that we’re assuming default export options in this comparison. Illustrator has a robust set of options that can completely change how an SVG file is saved, where the others do not. I decided to use the default Illustrator export settings, with the minor exception of not minifying the code on export.
All good? Let’s look at the results.
Side by Side Code Comparison
This was written in 2017. Apps like these evolve. Figma, for example, blogged about improvements they have made to SVG exporting. SVG has directly-blessed optimization plugins. And you should be optimizing your SVG anyway! 💪
Table Comparison
Comparison | Illustrator | Sketch | Figma |
---|---|---|---|
Export Settings | Yes | No | No |
File Size | 498 Bytes | 946 Bytes | 1 KB |
XML Header | No | Yes | No |
Includes and attributes | No | Yes | Yes |
Includes viewBox Attribute | Yes | Yes | Yes |
SVG ID | Yes | No | No |
SVG ID Name | Generated | NA | NA |
SVG Data Name Attribute | Layer Name | NA | NA |
Title Tag (<title> ) | File Name | Artboard Name | Layer Name |
Description Tag (<description> ) | NA | Created with Sketch | Created with Figma |
Includes Definitions (<defs> ) | No | Yes | Yes |
Includes Groups (<g> ) | Yes | Yes | Yes |
Group ID Name | NA | Organized by Page Name, Artboard, Group, then Layer | Organized by Frame, Group, then Layer |
Includes Use (<use> ) | No | No | Yes |
Comparison Summary
Those are some pretty interesting results. Like I mentioned earlier, the goal here is not to declare a winner of who does things best™ but to gauge whether there are differences — and there certainly are differences!
File Size
One huge benefit of SVG, in general, is its small file size versus raster images. That benefit shines in all three cases. For example, the same icon exported as a PNG in Sketch came out to 12KB. Sketch’s SVG output is 97% savings from its PNG counterpart.
I’m not particularly sure that the differences in file sizes between the three results here are all that crucial, despite the fact that Illustrator’s output results in a file size that is ~30% smaller than Figma’s output. I only say that because it’s likely that the SVG file that gets used in production gets minified and cached in the same fashion that makes it all very negligible.
That said, the fact that there is a file size difference at all might influence which build tools you use for your SVG workflow and how the settings for that build tool are configured.
Code Structure
The difference in file size really comes down to how each application structures the code it compiles. For example, where Figma is super into grouping and defining shapes and paths for the sake of making them more reusable in different contexts, Illustrator avoids them altogether and tends to make the file easier to drop inline.
Again, the goal is not to determine whether one approach is better than the other, but recognize that there are different philosophies going into the generated file and let that help determine the right tool for the current job. You might get a smaller file size in one instance, but perhaps more flexibility in another, depending on your needs and priorities.
Naming Standards
Another case in point is how Illustrator uses unique generated IDs on the <svg>
element by default. That makes dropping the file inline much less likely to conflict with other inline files where a designer may have used the same file, artboard or layer names across multiple files. By contrast, neither Sketch nor Figma uses an ID directly on the SVG element.
There are build tools that will help craft ID and class names but, if you are tasked with editing an SVG file manually or have to use a file as it’s provided to you for some reason, then knowing how an application names things might influence how you approach your work.
Wrapping Up
The biggest takeaway for me from this comparison is a reminder that SVG is code at the end of the day. The applications we use to illustration vector graphics are simply a GUI for creating code and the way that code gets written is likely to be different based on who is writing it.
It’s really no different than something like the CodePen Rodeo (when is the next one, by the way?) where a single design is provided and many people go off to code it in their own ways. There is no “right” way to code it, but it’s fun to see how different people take different paths to achieve the same deliverable.
The bottom line underscored by this comparison is that we can’t take the assets we have for granted. As much as we may enjoy the fact that machines are willing to make decisions on our behalf, a front-end workflow is still overwhelmingly a subjective task and influences how we do our jobs.
One side-effect of the automatically-added
<desc>
attribute from Sketch and Figma is that screen readers read this content to users. So using un-altered files from those two will make default advertisements for the products to visually-impaired users for each SVG included in your final layout.What? No love for Inkscape? :(
There are very fine detailed controls over how the SVG is built. And it’s open source / free. :)
Here’s a summary. I did a save as > Optimized SVG (default settings)
Size: 667bytes
I’m not smart enough to figure out the rest of that stuff. :) But it’s pretty clean, with white space even stripped out. Cheers!
For anyone exporting SVG in sketch I’d recommend using the Compressor plugin they developed for it.
https://github.com/BohemianCoding/svgo-compressor
It can be very useful for cutting out all of the useless extra junk like IDs and such, and in the end gives you a lot more control than Illustrator does in export.
The same image, hand-coded:
Ya! that’s the way to do it – and now optimized with SVGOMG is only 154 bytes :)
This (or two
<rect>
s) would be my preference for this exercise, but I’m old fashioned. :)Though most the svg stuff I work on is conceptually very simple.
Minified it’s 154 bytes.
Ha, yes! Including a hand-coded version in my comparison would have really driven the point home that SVG is code at the end of the day and that we cannot always rely on what software generates for us.
As soon as I saw the image the top, this code popped into my head too. Then I saw polygons and groups being used and thought “that’s not right”.
So satisfying!
Why not do
instead?
That has the + as a single element, and uses a 100×100 canvas (easy with percentage thinking) instead of 96*96 with an -16 offset.
It’s also slightly smaller. 234b instead of 237b by default and minified to 147 bytes, or 141 bytes if you scale down the canvas. Or 144 bytes if you want to make it 16×16 for icon/scaling purposes.
Geoff, thanks for the article. You mention, “Applications have typically been consistent at saving JPGs, PNGs, and GIFs with perhaps minor differences to the overall file size.” I’d disagree on this point. I’ve found there are many inconsistencies in file size (sometimes hyuge) depending upon the file type and output settings (even/epecially with app defaults) of the source application. SVG seems to be no stranger to this either – especially depending on the user and how they approach the overall build of the graphic.
Also – A quick run through with your source output from the three apps into SVGOMG (using the defaults) gives us very different results – showing now Sketch to get thew smallests file size over AI. https://jakearchibald.github.io/svgomg/
Illustrator: 311 bytes
Sketch: 244 bytes
Figma: 411 bytes
After optimizing with SVGOMG, Sketch’s output has the smallest filesize (338 bytes) compared to Illustrator (510 bytes) and Figma (759 bytes):
Illustrator:
Sketch:
Figma:
Perhaps you and I have had different experiences with exporting files from applications. In my experience, no two exported files have ever been the same. They might ‘visually’ look very similar (just like SVG), but the underlying code is vastly different. Transparencies are often dealt with differently, colour matching is a pain, metadata is added/removed/changed, and on and on.
The difference is, with SVG we are more likely to be relying on the underlying code at some point in the future than JPEG. So now we notice that all black circles may not be equal.
And here is the result with Affinity Designer SVG export:
Size: 726 bytes
and the related code:
Thanks for that interesting comparison session!
Here is my take on this SVG build with Affinity Designer.
Depending on your settings, Illustrator does indeed export width & height.
•
<g>
if something is grouped•
<defs>
when using CSS styling to class names• width & height when “responsive” settings are disabled
I’ve found Illustrator to be the most flexible of the batch personally.
By reducing the dimensions to the smallest whole numbers, you can eek out even more file size. Because it’s SVG you can scale it back up no problem!
It’s no real surprise that Sketch wins the minified-size race, as other commenters have noticed, because it’s the only one of the three applications that actually used the
<circle>
primitive in its output code. There’s no more efficient way to define a circle than with<circle>
.In fact, Sketch’s unminified output only loses to Illustrator because of all the space it wastes with some odd choices. The use of explicit
<open>
and</close>
tags for all markup is especially weird, since SVG makes extensive use of empty elements that could be written<tag />
(as both other applications do). But there’s also the inclusion of that superfluous empty<defs></defs>
stanza. I suppose both could be explained by a template-based generator that simply doesn’t optimize for either empty elements or unnecessary containers, but I sort of wonder if there’s some kind of compatibility reasoning behind those choices, especially<defs></defs>
.Regardless, all of that is just “packaging” — in terms of the actual code sections of the result, the Sketch code is by far the most efficient representation of the drawing. Not calling a circle a
<circle>
leaves the other two having to fake it with relatively complex structures . (However, you didn’t say exactly how you created the circle in each application, which could affect how the output is generated. Perhaps Illustrator and Figma will output<circle />
tags, under the right circumstances.)I know you said up front that “this post is not at all concerned about the ‘best’ export”, but including file size in the output comparison table sort of does invite ranking the results. So I thought it was worth recognizing that Sketch ‘s output is actually fairly close to what someone might hand-code to achive the same result. At least from this one test, Sketch’s output is easily the most optimiz-able (as commenters’ testing has confirmed) — even if its own SVG code generator is somewhat lacking in efficiency.
One thing I’ve noticed over time is that SVG illustrations can be reduced quite a bit if you take advantage of strokes and
viewBox
. And, in general, code can be reduced if you take advantage of defaults.I made a hand coded version in under 140 bytes this way. Could fit in a tweet:
New idea!
SVG golf:
One receives a vector of a mini-golf hole and has to reproduce it with the smallest code.
The three SVGs are not comparing like with like. The Illustrator version has two black circles and one white cross, the Sketch version has one black circle and one white cross and the Figma version has one black circle, one white cross and two light grey squares. Were they drawn that way, or were the extra objects from Illustrator and Figma just created on save/export?
For what it’s worth, I created the same object in CorelDRAW and it exported at 1,079bytes. I find it odd that only Sketch and CorelDRAW exported the circle as a
<circle>
.“. I find it odd that only Sketch and CorelDRAW exported the circle as a .”
Me too – I also see that Affinity Designer allows copying as SVG. So here’s the strange part. I made a simple circle; copied it and pasted it into my editor – they use in the clipboard copied code. Then saving the file as SVG, I was surprised to find the same circle was converted to data. I’m going to guess two different sets of code or two different developers worked on these modules.
It is certainly interesting there were two circles in the Illustrator version. I no longer have the source file but attempted to redraw based on a tracing of the original and it came out with a single path this time around. That significantly cuts the size as well. Must have been my mistake and I’ve updated the comparison pen. Nice catch!
The Figma rectangle kinda sorta makes sense because it must have exported the frame along with the icon. I’m sure that is a workflow preference that can be updated, but it wants to include that by default, which is how I tested all three.
I work on the SVG import/export of Figma. We are looking to address many of the SVG concerns in an upcoming update. This update would have been out long ago, but we have been busy on features like components, prototyping, and developer handoff.
In SVG, “defs” and “symbols” are a way to de-duplicate the scene and also organize data. On trivial examples, the defs blocks do add more code. Figma exports much more complex content though, but you could argue that the icon case could be optimized more.
There are two major contributors of text content in SVG files that create the most xml text. The first are embedded images (base64 encoded). The second is paths, and primitives are just a shortcut to specify a path. SVG “polygon” is just a path without curves.
On some of the first SVG exports I looked at from design tools, images and paths weren’t even put into defs blocks. The same 4MB image was embedded as base64 (taking it to 10MB) 20 times in a file. Paths were repeatedly inlined, making the style data difficult to read. Illustrator takes this one step further, and has an option to isolate the style in a “style” block, which are just defs for styles.
You can inline all sorts of things in optimizing the files, but those come with tradeoffs. Trivial examples like these, don’t convey the compression of deduplicating data, or the convenience of changing by hand data that is deduplicated across a document. SVG, ultimately, isn’t a human-readable or human-modifable format on the scenes that I export.
So the synopsis is that you can’t totally optimize for one of – final file size, readability, transfer, and rendering without compromising some aspect of those 4 things. In the case of Figma, we currently (and I emphasize that) only have a single export setting that has to try to optimize those 4 things.
I’d like to also bring up that SVG hasn’t been modified in 20 years. We’re still on the 1.1 spec, and I haven’t seen much interest in moving it forward. The browsers have done the most here, with great import and rendering. Try the same with the big vector tools, and you’ll be surprised. A one of everything test is pretty eye opening, and most can’t read their own SVG data, or others SVG files.
I like to say SVG is a very lossy format because the current design tools all import SVG poorly. This is one of the biggest constraints even if you export beautiful SVG data. Inside/outside stroke doesn’t exist in 1.1, Android Studio doesn’t even parse defs, Illustrator crashes importing SVG masks, Sketch/Illustrator paste XML when SVG is on the clipboard, gradient/image transforms don’t import, patterns are skipped, etc.
I’m hopeful since Xcode 9 is finally supporting SVG. It’s a reasonable vector format for some things, but vector tools have evolved to a richer set of data like vector networks in Figma. SVG has an effects system which is great compared to PDF. PDF wasn’t really built with transparency, or screen design in mind. It’s still tied to print. There needs to a better vector format, and we hope that Figma can address that.
When I first came across the idea of using vector formats in browsers, I had to deal with VML and then because it was the Great Browser Wars learning and using it only specific to certain scenarios (such as corporate desktops where you were guaranteed to have an IE4 or 5 browser). Then there was this giant gap before SVG started being supported by the open browsers. I think that’s why the spec hasn’t progressed: no reason to.
These days as everybody uses fonts for icons, and even these are slowly tending towards SVG because of the easiness of modifications or colouring or variations. It’s no real wonder that tools haven’t concentrated on the format itself or pushing its capability. What people can do with it is pretty impressive, even if we wish we had stackable strokes and animatable filters and better clipping mask properties and so on.
I guess the correct optimisation strategy is to automate as much as you can, then tweak it by hand until its within acceptable limits. As shown in the thread replies above there’s many thoughts and variations of this specific icon (some tiny – 140 bytes was impressive!). But that’s in no way automatable since it requires the app to know what the user is trying to achieve: Sometimes they want all that layering and grouping inside the export so they can manipulate them through style or script.
I must admit, I’d not heard of Figma. I have Illustrator, Inkscape and Graphic and Gimp and quite a few other vector apps on my dev box even though I’m primarily a coder simply for comparing and hand-tweaking their export formats so I can DO optimisation (because designers, in my experience, often do not). Figma looks pretty cool for its position in the design workflow.