SVG optimiser

Shrink an SVG, and see what each risky setting costs before you use it.

401 characters · 8 lines

Or drop or paste anywhere on the page. SVG files, any number.

Sample

  • Sample · example-mark.svg401 B
    Optimising…

Options

More optionsOptions that can break the file: all off

Options that can break the file

Optimising with the current settings…

What SVG optimisation is

Rewriting an SVG’s markup to remove editor metadata, collapse paths and reduce coordinate precision. The trap is that two of the settings which shrink a file most reliably also break it, and a byte count cannot tell you which happened.

What this tool does that others do not

  • The risky settings carry their consequence

    Dropping viewBox stops the file scaling: without it an SVG is locked to its width and height attributes and will not fill a container or respond to CSS sizing, which is the single most common way an optimised icon ends up the wrong size in production. Dropping <title> removes the accessible name, so a screen reader announces an informative graphic as nothing. Both are off by default, which matches what SVGO itself decided in version 4.

  • A preview beside the original

    A percentage tells you the file got smaller, not that it still works. The two are rendered side by side for the same reason the settings carry warnings — the point is to check rather than to trust the number.

  • The gzipped figure, because that is what ships

    Servers compress SVG in transit, and the raw byte count overstates the benefit: two optimisations that look equally good uncompressed often differ much less once gzipped, since compression already handles repetition. Both figures are shown.

  • Precision as the real lever

    Most of the available saving in a designer-exported SVG comes from coordinate precision, because design tools routinely write six or more decimal places that nothing can display. Three places is the default here and two is usually fine for icons; below two, curves start to visibly distort — which is what the side-by-side is for.

How to use it

  1. Paste the SVG as exported

    Editor metadata and unused definitions are where the first easy saving lives, and they are removed without risk.

  2. Drop the precision before anything else

    Try three, then two, watching the preview. This is where the bytes are.

  3. Leave viewBox and <title> alone

    Turn them off only for a purely decorative icon that is already hidden from assistive technology with aria-hidden.

  4. Compare the gzipped numbers

    If two settings differ by a lot raw and barely at all gzipped, take the safer one.

Worked example

Real input, real figures.

Benchmarking this against an older optimiser

You give it

The same icon through this tool and through a tool with the legacy default preset.

You get

This output can be slightly larger, and the reason is almost always that viewBox and <title> have been kept. SVGO removed both from its default preset in version 4 for exactly that reason — the smaller file was the broken one.

Against an optimiser scored on one number

AspectThis toolA byte-count optimiser
viewBoxKept by default, with the cost statedRemoved to win the comparison
<title>Kept — it is the accessible nameRemoved
PreviewSide by side with the originalA percentage
Size shownRaw and gzippedRaw only
EngineSVGO 4 running in your browserA server round trip

Guide

Smaller is not the only axis

SVG optimisers are scored on one number, and that is the problem. Two of the settings that shrink a file most reliably also break it: dropping viewBox stops it scaling, and dropping <title> removes its accessible name. In most tools these read as ordinary checkboxes next to a byte count.

Here they carry their consequence and stay off unless you choose otherwise, which matches what SVGO itself decided in version 4. The preview sits next to the original for the same reason — a percentage tells you the file got smaller, not that it still works.

Questions people ask

Straight answers. Each one links directly: copy the address after opening it.

Why is "remove viewBox" turned off?

Because it breaks responsive scaling and saves almost nothing. Without a viewBox an SVG is locked to its width and height attributes, so it will not fill a container or respond to CSS sizing — the single most common way an optimised icon ends up the wrong size in production. SVGO itself removed this from its default preset in version 4 for exactly this reason. If you are benchmarking us against SVGOMG or an older blog post and our output looks larger, this is usually why.

Why keep the <title> element?

It is the accessible name. A screen reader announces an SVG by its title, so removing it turns an informative graphic into an unlabelled one. It is safe to remove only for purely decorative icons that are already hidden from assistive technology with aria-hidden. Like viewBox, SVGO 4 no longer removes it by default.

What precision should I use?

Three decimal places is a good default and is what is set here. Two is usually fine for icons. Below two, curves start to visibly distort, which is why the preview sits directly beside the original — the point is to check rather than to trust the number. Precision is where most of the real saving in a designer-exported SVG comes from, because design tools routinely write six or more decimal places that nothing can display.

Why does the gzipped number matter more?

Because that is what a visitor actually downloads. Servers compress SVG in transit, and the raw byte count can overstate the benefit: two optimisations that look equally good uncompressed often differ much less once gzipped, since compression already handles repetition. Both figures are shown.

Is my file uploaded?

No. SVGO runs in your browser, loaded only on this page. You can disconnect and it will keep working.