Hi everyone, I built CEIR SVG Optimizer, a free Windows app that makes SVG files smaller without changing how they look.
If you keep UI icons or other art as SVG in your project, the exports from Inkscape, Illustrator or Figma often carry editor data, unused definitions and long numbers, and their outlines are cut into far more curve pieces than the shape needs. This removes all of that and joins curve pieces wherever the shape stays the same.
Before anything is saved, the original and the result are compared pixel by pixel, and you see both side by side with the change in file size, anchor points and element count.
It works on a single file or a whole folder, there’s a command-line mode for build steps, and your originals are never overwritten.
Search for CEIR SVG Optimizer in the Microsoft Store.
I could be wrong but as far as I know, SVG files get turned into what are essentially PNGs before they are used by the engine, so I’m not sure if optimising them will change much when it comes to game development.
This is true, Godot does not export games with SVG files in them, nor PNG or JPEG. Image files are converted into a rasterized and compressed version upon import, the compression type depends on import settings. Most import types are unique to game dev and won’t open in mspaint for example. This is what the .godot/imported folder contains.
Thanks both, that’s useful to know. So in a Godot project this won’t change what ends up in the exported game, since what ships is the imported version. The only gain would be smaller source files in the project.
Maybe it could be somewhat interesting for this project:
Especially for the new animated SVGs exported from Blender Grease Pencil. (I haven’t used animated SVGs or the addon yet.)
About how much optimization are we talking here? What is the average gain here?
I’m on Linux, no interest to get anything from the MS store. What about other OS? Is the source code available? Is it vibe coded?
To be clear: I have not implemented an importer for those yet, just put in on my roadmap for SVS 2D.
What adobe illustrator recently (past 3 yrs) did is put all inline style attributes inside a style block with classes… is it that sort of thing?
I imagine there are already a lot of svg optimizers out there from vendors like adobe, or open source via inkscape… when on linux I’d expect many shell wrappers to exist already.
But to answer the question: no, my plugin doesn’t necessarily keep the svg files after import.
However, when importing at runtime (because you want to pack a very very small size game for web in areas with low bandwidth) it would reduce a couple of extra bytes. Same goes for the auto-scaling UI, which all happens in-memory as well.
Yes, that reduction of “curve pieces” seems interesting, but I’d need a more explicit definition to know for sure.
Long numbers and editor data do indeed take up quite some space, then again, at least in inkscape you can turn that off as well.
I think all in all it would be especially useful if you are building an application with many many many gui icons. But wouldn’t packing as webp (or letting godot pack it) make a lot more sense in most cases? Very few people at the moment use actual scaling svg because it’s not built in.
What I would like more is a better version of the svg image preview because the Micro$oft “Power” tool is very very very very slow… If I want to look at a directory overview with 1000 icons it is simply not doable with the scary powersloptools.
On what joining curve pieces actually means, here’s the short version.
When you export an outline from Illustrator or Inkscape, one smooth curve often gets saved as several short pieces that follow each other. It looks the same on screen, it just takes more data to describe. The app looks at neighbouring pieces and joins them into one only if the shape stays the same. If the result would move, it leaves them alone. So it’s about the path data itself, on top of stripping editor data and unused definitions.
You’re right that this doesn’t change much for a normal export, since imported SVGs get rasterized. Where I think it could matter is shapes you keep as actual paths, like in Scalable Vector Shapes 2D, where fewer points would mean less to edit and animate.
I’ll come back with real numbers on the average gain.
But what if the rendering at another scale would make a smoother curve? I understand that there is a viewbox that determines resolution at render time and all, but the use case I’m working on is responsive scales and infinite zoom.
So when I read your definition of “the same shape”, to me personally it means: “the same shape, given the provided rendering resolution”. This is of course perfectly fine for most use cases that do not wish to scale up, but would mean information loss in use cases that do.
Even the built-in importer for godot allows you to pick a higher scale at import time which, that one time, allows for a higher resolution than the rendered resolution your tool tests with.
Most people will have some use for this, I am sure, so no worries… I’m just an old nit-pick really
@conz3d here’s the number I said I’d bring back: the average size reduction is about 39%. Files that were already exported clean will get less out of it, and ones full of editor data will get more.
@renevanderark no need to apologise, and you’ve read it right. The check renders the original and the result at the same size and compares them, so it can only speak for the size it was checked at. For infinite zoom that’s a real limit, so your use case is a harder test than most. The original never gets overwritten, so it’s easy to try on one file with the Safe preset and compare the two at your biggest scale.
Thanks all, this has been more useful than I expected. It sounds like a smaller source file isn’t what most people here need. @renevanderark the slow preview caught my attention. What would a good version look like for you, just a fast grid of a whole folder, or something more? And for anyone else working with a lot of SVGs, what’s the most annoying part of it right now?
That would be a great start, but a detail list with a 32x32 sized thumbnail that can be sorted by name and date would be best… What would be perfect is if it seamlessly integrates with the windows file explorer. (But I am not sure if that is still really for the forum… Though I’m sure more GUI developers have run into this)
PS: I will only install it if it is not built with the help of LLM and when it’s open sourced. Making it to the windows Store doesn’t cut it for me.
