Minify Your SVGs

Unfortunately the reference to the actual minifier, SVGO (<a href="https:&#x2F;&#x2F;github.com&#x2F;svg&#x2F;svgo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;svg&#x2F;svgo</a>), is buried in the middle of the post.<p>SVGO is an incredible project driven by a single volunteer in spare time (originally Kir Belevich <a href="https:&#x2F;&#x2F;twitter.com&#x2F;deepsweet" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;deepsweet</a> , and for the last few years Lev Solntsev <a href="https:&#x2F;&#x2F;twitter.com&#x2F;ruGreLI" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;ruGreLI</a>). It&#x27;s the type of project you probably use regularly behind another tool like Sketch or SVGOMG (<a href="https:&#x2F;&#x2F;jakearchibald.github.io&#x2F;svgomg&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jakearchibald.github.io&#x2F;svgomg&#x2F;</a>). They accept donations (<a href="https:&#x2F;&#x2F;www.paypal.me&#x2F;deepsweet" rel="nofollow">https:&#x2F;&#x2F;www.paypal.me&#x2F;deepsweet</a>) and you should definitely consider contributing if you find it useful.

Pro tip for people with SVGs that have an image inside. You can pull that base64 image out of the svg, convert to image, compress it (tinypng, pngcrush etc) then convert back to base64 and out back in the SVG. We automated this with a slackbot but it’s often overlooked with all SVG optimization scripts.

Related: <a href="https:&#x2F;&#x2F;jakearchibald.github.io&#x2F;svgomg&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jakearchibald.github.io&#x2F;svgomg&#x2F;</a>

Be aware that svgo is a lossy operation. One thing it does is round the digits in numbers to a certain precision. When I last worked with it, it also did some things I did not like such as mess with viewboxes. I found that it messed up the sizing of SVGs embedded with &lt;img&gt; tags in certain browsers. It has been a while since I used it though.

I absolutely love ImageOptim for manually optimizing SVGs, JPGs, PNGs, and GIFs. It&#x27;s a simple GUI that wraps some excellent compression libs (including SVGO), which I find much faster to use for one-off image optimization than the CLI. It does a clever job of trying multiple compressors and picking whichever one creates the smallest file for each image. You can run it in a lossless or lossy mode, and tune various compression options. It&#x27;s free (gratis), OSS, and runs on Mac, Windows, and Linux.<p>I make it a habit of running images through ImageOptim before sending them via Messages or Slack, as a courtesy for people on slow connections.<p><a href="https:&#x2F;&#x2F;imageoptim.com" rel="nofollow">https:&#x2F;&#x2F;imageoptim.com</a> (by HN user pornel)<p>Bonus round: When it comes to optimizing SVGs, nothing beats hand-editing the SVG source. I&#x27;ve done a fair bit of that optimizing the artwork for <a href="https:&#x2F;&#x2F;www.lunchboxsessions.com" rel="nofollow">https:&#x2F;&#x2F;www.lunchboxsessions.com</a> and it&#x27;s been totally worth the effort. Taking a detailed 10k SVG down to 500 bytes with no perceptual difference is a huge win when you have hundreds of those SVGs on the page and you serve people who still use dialup.

Yet another alternative that has benchmarks against svgo and scour is svgcleaner: <a href="https:&#x2F;&#x2F;github.com&#x2F;RazrFalcon&#x2F;svgcleaner" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;RazrFalcon&#x2F;svgcleaner</a>.<p>It is written in Rust and has been my go to for SVG optimization due to its speed.

Would be more compelling with the sizes of that neutral net in the different passes. As it is, this is like comparing two algorithms on a small dataset without accounting for growth in data on behavior.

There&#x27;s also <a href="https:&#x2F;&#x2F;vecta.io&#x2F;nano" rel="nofollow">https:&#x2F;&#x2F;vecta.io&#x2F;nano</a>, which I&#x27;ve found to sometimes give better results than SVGOMG

A related (but less automated) advantage is if you&#x27;re building react components that render SVG, this minified output will be much shorter and hopefully easier to reach through and figure out where you want to insert your own colours&#x2F;child components.

Illustrator has an export SVG function (as opposed to just saving as an SVG, which I was doing and then using a minifer for a long time) that will minify it for you.<p>That said, it currently appears unable to reopen those minified SVGs (go figure).

I love seeing efforts to make software more efficient, so I enjoyed this post, but at the same time your own blog has a 434kb 512x512 png favicon. I&#x27;m not at all a web developer and so I don&#x27;t know if there is a technical reason for that, but it seems a bit absurd in juxtaposition to your goal to reduce a 2kb svg to 100 bytes.<p>I&#x27;ve seen this on a number of other blogs, which seem to focus on minimal design. Can anyone explain what the need is for these enormous favicons?

Don’t forget to also use GZip or another transport compression on them as well. Text tends to compress well, and can net additional benefits on top of minification.

This is neat, but I wonder: are there path optimization tools? For instance: flattening, removal of entirely occluded paths, and combination of paths.

SVG optimization seems like a good choice for delivery, but oftentimes I find myself using SVG in a development context. Having human readable, annotated SVG files is useful when looking through previous revisions. In terms of compressed filesize: there&#x27;s no serious practical gain.

Aren&#x27;t garden variety SVG files ~75% smaller than other lossless compression methods (e.g. PNG). As such, is minification necessary or a best practice?<p>In short, is this an intellectual exercise or something that should be in an SVG producer&#x27;s toolkit?

This is an excellent post!<p>It does a fantastic job of defining the problem and walking the reader through the process of solving it. The language is so succinct and clear that even if the reader had never heard of SVGs before, they would understand this post.<p>Well done, Victor!

Nice work, svgo is awesome. I&#x27;d love to adapt this to a non-gatsby post-build tool that also runs image compression on any jpg&#x2F;png files.<p>Big advantage to running post-build besides convenience is that sometimes Inkscape doesn&#x27;t render optimized svg&#x27;s correctly. So I have to keep originals elsewhere.

We provide hosted service for optimising SVG. If anyone is interested for image optimisation as a service, take a look here: <a href="https:&#x2F;&#x2F;www.gumlet.com" rel="nofollow">https:&#x2F;&#x2F;www.gumlet.com</a>

For inlining, you can even go further and remove that xmlns attribute to end with something around 50 bytes. I&#x27;d recommend keeping the viewbox though, since it&#x27;s required for proper resizing.

Most of the time, automated optimizers for SVG are relatively bad, though, and rewriting the SVG by hand can get a 2KiB svgo result down to 200 bytes or less.

Don&#x27;t SVGs have to have an XML declaration? I think that magic will fail to identify the content type of an SVG if it&#x27;s not a valid XML file.

Very neat! Now just need to figure out how to plug svgo into my jsx rendering pipeline, at build time.

I&#x27;ve also noticed the cruft in Inkscape SVG&#x27;s.<p>The TXR logo SVG is cleaned with a TXR script:<p><a href="http:&#x2F;&#x2F;www.kylheku.com&#x2F;cgit&#x2F;txr&#x2F;tree&#x2F;win&#x2F;cleansvg.txr" rel="nofollow">http:&#x2F;&#x2F;www.kylheku.com&#x2F;cgit&#x2F;txr&#x2F;tree&#x2F;win&#x2F;cleansvg.txr</a><p>The original looks like this:<p><a href="http:&#x2F;&#x2F;www.kylheku.com&#x2F;cgit&#x2F;txr&#x2F;tree&#x2F;win&#x2F;txr.svg" rel="nofollow">http:&#x2F;&#x2F;www.kylheku.com&#x2F;cgit&#x2F;txr&#x2F;tree&#x2F;win&#x2F;txr.svg</a><p>The cleaned one is not in the repo. It&#x27;s obtained by &quot;txr cleansvg.txr txr.svg&quot;:<p><pre><code> &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;no&quot;?&gt; &lt;!-- TXR Logo Copyright ... --&gt; &lt;svg xmlns=&quot;http:&#x2F;&#x2F;www.w3.org&#x2F;2000&#x2F;svg&quot; viewBox=&quot;0 0 277.4375 297.4375&quot; id=&quot;svg2&quot; version=&quot;1.1&quot;&gt; &lt;g transform=&quot;translate(-200.03125,-416.34375)&quot;&gt; &lt;g transform=&quot;matrix(3.078678,0,0,3.078678,-1110.4532,-1582.3752)&quot;&gt; &lt;path d=&quot;m 476.96875,651.28125 c -7.29171,7e-5 -14.03911,1.37247 -20.21875,4.125 -6.17972,2.75267 -11.36983,6.39069 -15.5625,10.875 -4.33856,4.5938 -7.66668,9.81776 -10,15.6875 -2.33334,5.86983 -3.50001,11.92191 -3.5,18.15625 -10e-6,7.29167 1.28645,13.62241 3.875,19 2.58853,5.3776 6.02082,9.89063 10.25,13.5 4.26559,3.60937 9.05205,6.29426 14.375,8.0625 5.32287,1.76822 10.74475,2.65623 16.25,2.65625 6.1614,-2e-5 11.73692,-0.987 16.75,-2.9375 5.01294,-1.95054 9.35409,-4.51564 13,-7.6875 l -1.71875,-2.78125 c -3.60945,2.98957 -7.66675,5.27603 -12.1875,6.84375 -4.5209,1.5677 -9.67194,2.34374 -15.46875,2.34375 -5.14067,-10e-6 -9.93234,-0.82814 -14.34375,-2.46875 -4.41149,-1.64064 -8.224,-4.09376 -11.46875,-7.375 -3.31773,-3.39062 -5.89586,-7.61198 -7.71875,-12.625 -1.82294,-5.013 -2.71877,-10.80728 -2.71875,-17.40625 -2e-5,-6.85413 1.16665,-13.00517 3.5,-18.4375 2.33331,-5.43223 5.36976,-9.94787 9.125,-13.59375 3.86454,-3.75515 8.14059,-6.59889 12.84375,-8.53125 4.70307,-1.93222 9.54162,-2.90618 14.5,-2.90625 5.21348,7e-5 9.82806,0.80215 13.875,2.40625 4.04679,1.60423 7.40096,3.79174 10.0625,6.5625 2.77074,2.80735 4.83846,6.02349 6.1875,9.6875 1.34887,3.6641 2.03116,7.66672 2.03125,11.96875 -0.1377,8.31795 -2.4429,16.899 -11.71184,23.81796 -4.24484,3.16863 -9.29313,4.01343 -14.18104,4.49201 -2.5623,0.25088 -7.11725,0.30793 -9.74156,0.25794 -1.81112,-0.0345 -3.02482,-0.27866 -3.74043,-0.81795 -0.71564,-0.53929 -1.06251,-1.22605 -1.0625,-2.0625 -1e-5,-0.90247 0.57819,-3.28219 1.71875,-7.15625 l 7.90625,-28.15625 3.59375,0 c 3.15321,4e-5 5.11461,0.28996 5.875,0.90625 1.00632,0.81447 1.49996,2.04944 1.5,3.65625 -4e-5,1.36476 -0.20014,2.91736 -0.625,4.65625 l 2.78622,0 4.09375,-13.875 -37.14277,0 -3.53125,13.87504 2.29405,0 c 0.62617,-2.3112 1.42225,-4.1203 2.40625,-5.375 0.98398,-1.25462 2.27599,-2.21462 3.875,-2.875 1.59897,-0.66031 3.69596,-0.96871 6.3125,-0.96875 l 2.71875,0 -8.34375,29.125 c -0.93928,3.16968 -1.69323,5.23924 -2.21875,6.21875 -0.52556,0.97952 -1.10147,1.65706 -1.75,2.03125 -0.93928,0.55029 -2.28692,0.8125 -4.03125,0.8125 l -0.875,0 -0.96875,3.46875 19.90942,0.12627 c 4.65825,0.0295 14.28759,-0.73275 17.58443,-1.82102 6.80584,-2.24657 10.97411,-5.63785 13.61133,-8.47036 1.87071,-2.00924 7.5173,-9.18725 7.82441,-20.78032 0.12261,-4.62853 0.078,-9.57025 -1.39847,-13.83592 -1.47666,-4.26557 -3.67197,-8.03119 -6.625,-11.3125 -2.95321,-3.31763 -6.74488,-6.00774 -11.375,-8.03125 -4.63028,-2.02336 -10.09903,-3.03118 -16.40625,-3.03125 z&quot;&#x2F;&gt; &lt;&#x2F;g&gt; &lt;&#x2F;g&gt; &lt;&#x2F;svg&gt;</code></pre>

Why? Why minify everything? It all gets gzipped at the HTTP layer anyway! I truly cannot understand this need to minify everything (JS included)

In general I&#x27;d recommend the opposite: don&#x27;t minify anything unless necessary, prettify it instead. Every plaintext-based format file should be optimized for human readability unless you actually need to make it hard to read (e.g. you are developing a proprietary product not meant to be open-source) or your bandwidth is limited so severely that every single byte matters.<p>Nevertheless the kind of minification demonstrated in the example (removing Inkscape bloat) feels really great and actually makes the file more human-readable. This reminds me of HTML files generated by MS Word and other WYSIWG editors which included tons of bloat code that actually harmed rendering (needless to say human readability).