One Illustration, Three SVG outputs

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.