Shrink an SVG in the Browser: What the Optimizer Deletes and What It Leaves Behind

I work on OnePassApps, the team behind the browser-local studios at app.onepassapps.com. The Icon Studio has an Optimize SVG tab, and the question that matters is not how small the file gets - it is what the tool throws away while making it small.

What the panel promises

The page opens with "Create icons and favicon assets on this device. Files stay in your active browser tab." and the tab itself is three steps:

• 01 Source - "No SVG yet. Drop one on the stage or browse for it. SVG up to 5 MiB and 25,000 elements."
• 02 What changes - three labelled rows: "Keeps" / "The viewBox and every visible shape", "Removes" / "Scripts, event handlers and external references", "Compares" / "The byte sizes before and after". This morning's run of the same tab recorded that same promise as one sentence: "The optimizer keeps the viewBox and every visible shape and removes scripts and external references."
• 03 Result - "A smaller, safe SVG, with the file size before and after."

That is a promise about safety, not only about size, so I tested it against a deliberately dirty file instead of a tidy one.

The file I gave it

I hand-built a 128 x 128 SVG, 963 bytes, carrying everything an export tool leaves behind: an XML declaration, an editor comment, a metadata block, a title and a description, a script element, an onload event handler on the rectangle, an external image reference pointing at a tracker image on another host, an unused gradient, a group id, a no-op transform, and coordinates written out as 8.0000000.

The source stage named the file and its size - this morning's run recorded "probe-optimize-in.svg - SVG - 128 x 128 - 963 B". Later the same day the Source stage renders the loaded file as "hostile-probe.svg - SVG - 200 x 200 - 1.3 KiB" with a "Replace" and a "Remove" control beside the name - that was a deliberately hostile test file I used to probe the tab, and I did not finish the optimize run on it, so I make no claim about what it strips. Read the size off your own file.

What came out

The result stage read: "probe-optimize-in-optimized.svg - SVG - 612 B", with a Download SVG button and the line "SVG reduced by 351 bytes (36%)." The arithmetic matches the bytes on disk: 963 - 612 = 351.

I downloaded the optimised file and read it outside the browser. Removed - every one of them gone from the output bytes:

<script> element            0 occurrences
onload="alert(...)"        0 occurrences
xlink:href / any href      0 occurrences
example.com                0 occurrences
<metadata> block            0 occurrences
<!-- comment -->            0 occurrences
<?xml ...?> declaration     0 occurrences

Kept - still in the output bytes:

viewBox="0 0 128 128"      kept
<title>Probe</title>        kept
<desc>...</desc>           kept
<defs> with unused gradient kept (id="unused" and all)
<g id="layer1">            kept
transform="translate(0.0...)" kept
x="8.0000000"              kept, precision untouched
<image x="0" y="0" .../>    element kept, source gone

The three findings

The external reference is removed by dropping the attribute, not by deleting the element. The image tag survives with its x, y, width and height intact and no href at all, so the file still contains an image element that renders nothing. If that bitmap was doing work in your icon, the optimised file is a different drawing - check it before you ship it.

The unused gradient is not unused any more. The defs block, the gradient and its id all survive, even though nothing references them. The optimizer removes active content, not dead weight.

Precision is left alone. Coordinates written as 8.0000000 stay 8.0000000, and the no-op transform stays too. Part of the saving comes from somewhere else: colours are normalised on the way through. stop-color="#ff0000" came out as stop-color="red", "#0000ff" as "#00f", and fill="#58A0D6" as fill="#58a0d6".

So the byte saving is a mix of three different things - deleted metadata, shortened colours, and dropped attributes - and only one of them is what the panel advertised.

A second sample, so the number is not a one-off

I ran a second, smaller file through the same tab: 387 B in, 238 B out. The detail panel read "Before 387 B SVG, After 238 B SVG, Size change 38.5% smaller", the summary line said "SVG reduced by 149 bytes (39%)", and the run reported "Created in 0.3 s". The percentage tracks the file, not a fixed setting - read the number on your own file.

Where it runs

The page states "Processing stays in this browser." and the file you drop is never rewritten in place - you get a new file next to it, and "Your original stays untouched."

You can try it here: the Icon Studio. The other studios are listed on the guides page.

One membership covers all seven studios, and Standard is free right now: $0 a month, 100,000 credits every 30 days, no card required. The studios need no account and use no credits.

What I did not check

• Signed-in behaviour - the studio was signed out in my browser.
• Whether the output still renders identically in every SVG consumer. I read the bytes, not every renderer's parser.
• Whether the optimizer ever touches the viewBox beyond keeping it.
• Any other optimizer, so I make no comparison to other tools.