ALL DEVELOPER TOOLS56
SVG Optimizer
SVG Optimizer — Minify SVG Files in Your Browser
Run SVGO on a vector file without uploading it, and read exactly what each pass took out.
Nothing is enforced, but the whole file is parsed into one object per element and per attribute, held in this tab while thirty-odd passes rewrite it, and the run blocks the page until it finishes — so the ceiling here is this tab's own memory rather than a cap set for you.
About SVG Optimizer
An SVG is text, and in most files the drawing is the smaller half of it. Anything exported from Illustrator, Figma or Inkscape arrives carrying an XML declaration, a DOCTYPE, editor namespaces, generator comments, layer names and coordinates written to six decimals on a canvas a hundred units wide. SVGO takes all of that out, and it is what almost every build pipeline already runs. Here it runs in your browser instead: parsed, rewritten and handed back inside the tab, with nothing uploaded. What this page adds is an account of what happened. It prints the bytes before and after and the percentage between them, read off the run rather than promised in advance — including the runs where the file comes out larger, which can happen to a drawing built on XML entities. And it names the seven default passes that can change more than the size: the one that renames and deletes ids, the one that dissolves the stylesheet, the one that drops attributes it does not recognise. Each is a checkbox that reports what it did to your file, not what it does in general.
Questions
The icon still looks right, but the hover colour and the animation stopped working.
Three of SVGO's default passes will do that, and the page names whichever one fired on your file. Inlining the stylesheet writes each rule onto the element it matched and removes the class it matched on, after which a :hover, :focus or @media rule has nothing left to attach to and is dropped as unused. Collapsing groups dissolves a <g>, so a transform or SMIL animation written against that group loses its element. And the id pass renames or deletes ids, which breaks a CSS or JavaScript hook that pointed at one. Untick those three, or start from the Safe preset, which has all seven risky passes off.
Does this strip the viewBox out of my file?
No, and it has not been true of SVGO for several major versions. removeViewBox is not in SVGO 4's default preset — the unit tests behind this page assert that against the shipped plugin list, so if it ever came back the assertion goes red before the page does. removeDimensions is not a default either. This page offers dropping the root width and height as an explicit checkbox, off unless you tick it, and when you do it writes a viewBox from the old width and height first if the file did not already have one, so the aspect ratio survives — but only where both are plain numbers. A root sized in mm, in, pt, em or % is left exactly as it is, because building a viewBox from it would mean guessing at a scale; the page says so above the panes rather than letting you ship a file you believe was made responsive. The viewBox is never removed here at all.
SVGO says it saved 60%, but my gzipped bundle barely moved.
Both numbers are real, and neither predicts the other. The figures here are UTF-8 bytes on disk; your server almost certainly compresses the file again on the way out. Which of the two savings is larger depends on what came out. Cutting repetitive boilerplate — namespaces, repeated attribute names, whitespace — barely moves the gzip number, because gzip was already collapsing it: this site's own 438-byte icon saves 26% raw and 19% gzipped. Cutting high-entropy content such as long unique decimal coordinates moves it more, and a 471 KB path drawing saved 50% raw against 73% gzipped. Measure the figure that matches how you ship the file.
A client sent me an SVG and I want to know whether it can run code.
It can, and this page tells you so rather than quietly deciding for you. Removing scripts is not part of SVGO's default set, so a <script> element and any onclick or onload attributes come through the optimiser untouched — the warning above the panes counts them and says they are still in the output. Whether that matters depends on how the file is used: browsers do not run script in an SVG loaded through an <img> tag or as a CSS background, and they do when the same file is pasted inline or opened as a document. Tick SCRIPTS AND HANDLERS, under ALSO REMOVE, and the page strips both, reporting how many of each it took out.
My file came out bigger than it went in.
Then the page says so, in bytes, and tells you to keep the original. There are two usual causes. If the file declared XML entities in its DOCTYPE, every use is expanded in place while the declaration is dropped, so text written once and referenced ten times is written out ten times — a test fixture of that shape comes back at more than twice its original size. The other cause is a file that has already been through an optimiser, where there is nothing left to take out and the byte counts come back equal. Neither is a failure of the run; both are answers, and the page prints them rather than rounding a loss up into a saving.
Is my file uploaded to a server?
No. Transmute processes everything locally in your browser using JavaScript and WebAssembly. Your files never leave your device — there is no server, no upload, no cloud processing.