How to make an SVG smaller without breaking it

An SVG exported from a design tool is mostly text that the browser throws away: editor metadata, comments, and coordinates written to six decimal places. Removing that is safe. The trouble is that two of the settings that shrink a file most reliably also break it, and a byte count cannot tell you which happened.

Optimise an SVG with the tool

1. Open the SVG optimiser. Paste your markup into the box labelled SVG markup, or press Open SVG files under it, or drop SVG files anywhere on the page; several files are optimised together, each on its own card. The box starts with a small sample icon, and its count line says how many characters and lines it holds.
2. There is no button to press: every file is optimised again whenever you change its text or a setting. Read the figures in Result: Before, After, Saved, and Gzipped (before → after, “which is what ships”). Each file’s card shows its own before and after.
3. Move Coordinate precision. It runs from 0 to 6 decimal places and starts at 3. Below 2, a warning appears under the slider.
4. Leave Run repeatedly until it stops shrinking ticked. It is on by default and repeats the optimisation until a pass saves nothing more.
5. Open More options to see Options that can break the file: Remove viewBox, Remove <title> and Shorten and drop unused ids. Each is unticked, and each says what it costs under its name. The line under More options says which are on, and Result names any that are, even with the group closed.
6. Compare the two rendered previews, labelled Original and Optimised. If they differ, the last setting you changed did it.
7. Press Download optimised SVG (or D) to save the result, as optimised.svg for pasted markup or logo-optimised.svg for a file called logo.svg, or Copy SVG code (or C). With several files, All 3 as .zip saves them together.

What each setting removes, and what it can break

Setting	Starts as	What it saves	What it can break
Comments, editor metadata, unused definitions	Always on	The easy bytes in any design-tool export	Nothing you can see
Coordinate precision	3 decimal places	Most of the saving in a typical export	Curves, below 2 places
Run repeatedly	On	Whatever a single pass left behind	Nothing
Remove viewBox	Unticked	Very few bytes	Scaling
Remove <title>	Unticked	The title’s text	The accessible name
Shorten and drop unused ids	Unticked	The id strings	External CSS, scripts, and <use> references from other documents

Precision is where the bytes are

Coordinate precision is the number of decimal places kept on each number in the file. Design tools routinely write six or more, and no screen can display the difference.

The tool’s own sample shows the scale of it. Its tick mark is drawn by this path:

M 16.000000 24.000000 L 22.000000 30.000000 L 32.000000 14.000000

That string is 65 characters long. Each of its six coordinates carries a decimal point and six zeros, so 6 × 7 = 42 of those 65 characters say nothing at all. When the trailing digits are not zeros, in an icon drawn at its intended size they still describe a difference far smaller than a pixel, and that is what the slider trims: three places is the starting point, two is usually fine for an icon, and below two the curves visibly distort. The side-by-side preview is there so you can watch that happen rather than trust a percentage.

The two settings that break files

A viewBox is the attribute that maps a drawing’s internal coordinates onto whatever box the SVG is drawn in. It is what lets one file scale to any size. Remove it and the SVG is locked to its width and height attributes: it will not fill a container or respond to CSS sizing. That is the most common way an optimised icon ends up the wrong size in production, and the setting saves very few bytes in return.

The <title> element is how a screen reader names an SVG. Remove it and an informative graphic is announced as nothing. It is safe to remove only from a purely decorative icon that is already hidden from assistive technology with aria-hidden.

SVGO, the engine the tool runs, took both of these out of its default preset in version 4 for exactly these reasons. If you compare the tool’s output with an older optimiser and this one comes out slightly larger, a kept viewBox and title are almost always the difference. The smaller file was the broken one.

Check your ids by hand

Ids are the quieter risk. If anything outside the SVG refers to an id inside it (a stylesheet, a script, or a <use> element in another document pointing into a sprite sheet), shortening or removing that id breaks the reference without any change you can see in the preview, because the preview shows the file on its own.

So leave Shorten and drop unused ids unticked for anything another file points into, and tick it only for a standalone icon, where nothing outside the file cares. For a sprite sheet, the ids are the whole interface.

That box did not always do what it said. While writing this guide we found that SVGO 4.1, the version the tool runs, still includes its id clean-up in the default preset, so ids were shortened or dropped even with the box unticked. The tool now switches the clean-up off explicitly when the box is clear, and a test in the site’s code checks both directions. If you optimised a sprite sheet here before October 2026, search the output for the ids your site relies on.

Raw bytes overstate the saving

Servers compress SVG in transit, and compression already handles repetition. Two results that look far apart uncompressed often end up much closer once gzipped, which is why the tool shows the gzipped figures beside the raw ones. If a risky setting buys a large raw saving and almost nothing gzipped, take the safer file.

Other ways to do it

SVGO also runs from the command line:

npx svgo input.svg -o output.svg

That uses SVGO’s default preset. In version 4 and later, the default keeps viewBox and the title element, as the tool does. For precision and the other settings, see SVGO’s own documentation. There is no built-in SVG optimiser in macOS or Windows.

Checking nothing was uploaded

SVGO runs in the tab. The first time the page optimises anything, which happens as soon as the sample loads, your browser downloads the SVGO code itself, about 195 KB gzipped; that is the one request you will see in the developer tools Network panel, and it comes in rather than going out. After that, you can disconnect from the network, paste your own file, and the tool keeps working.

Next

Paste your file into the SVG optimiser, take precision down to two, and compare the previews. If the SVG is a logo on its way to becoming a favicon, the Favicon generator accepts it directly. If you plan to inline it in CSS, the Data URI converter tells you whether that is worth doing.