How to optimise SVG files and reduce file size

An SVG should be one of the lightest things on a web page. It is just text that describes a few shapes, so a clean interface icon can weigh a few hundred bytes. Yet the SVG you drag out of Figma, Illustrator or Sketch is often ten or twenty times that size, padded with editor notes, hidden layers and coordinates carried out to six decimal places. None of it changes how the icon looks. All of it slows your pages down.

This guide explains exactly what bloats an SVG, how to strip the waste with the standard tools, and how far you can safely push the settings before crisp artwork starts to distort. If you are unsure what the format is to begin with, read what an SVG file is first, then come back here.

Why SVG files get heavy

An SVG is XML, a text format, so anything written into the file adds bytes whether the browser uses it or not. Design tools write a great deal. When you export, you typically inherit:

• Editor metadata. Namespaces and tags from the tool, such as xmlns:sketch, Inkscape attributes, or a <metadata> block describing the document. The browser ignores all of it.
• Comments and generator notes. A line like <!-- Generator: Adobe Illustrator --> and similar do nothing on the web.
• Over-precise coordinates. A point at 12.0000001 reads identically to 12 at icon scale, but the long form costs extra characters on every single number, and an icon can hold hundreds of them.
• Redundant groups and transforms. Tools wrap shapes in nested <g> elements and apply transforms that could be baked straight into the path.
• Hidden and empty elements. Layers you switched off, clipping paths nothing uses, and empty definitions still ship in the file.
• Inline styles and default attributes. Properties set to their default value, such as fill-opacity="1", add weight without changing anything.

Put together, this is why a 300-byte icon arrives as a 6KB file. The artwork is fine; the wrapper around it is the problem.

Measure before you optimise

Optimisation is satisfying to guess at and easy to overdo, so start with a number. Check the file size of one of your icons in your file manager, or run it through a checker. Note it down. After cleaning, compare. You want to see the real reduction, and you want to catch the rare case where a setting broke the artwork rather than shrinking it.

A useful rule of thumb for what good looks like once you are done: a single-path interface icon should land somewhere between a few hundred bytes and roughly one kilobyte. A more detailed icon with several paths might reach two kilobytes. If your icons are still five or ten kilobytes after a pass, they are carrying something an optimiser should have removed, so it is worth checking the settings.

Clean it with SVGO

SVGO is the standard tool for this. It is free, open source, and removes redundant data while rewriting the markup more efficiently. There are two easy ways to use it.

The web version, no install. SVGOMG is a browser front end for SVGO. You drop an SVG in, toggle the options, watch the size drop live, and download the result. It is the fastest way to clean a one-off icon and to get a feel for what each setting does.

The command line, for many files. If you have Node installed, you do not even need to install SVGO globally:

npx svgo icon.svg
npx svgo --folder ./icons --recursive

The first cleans a single file in place. The second walks a folder and optimises every SVG inside it, which is what you want for a whole icon set. Add --multipass to let SVGO run several rounds and squeeze a little more out of complex files.

If you would rather not run anything at all, the icons you export from the ICON OOP tool are already clean. The library ships optimised source files, so a single icon downloaded from here does not need a second pass before it goes live.

The settings that matter

SVGO applies a sensible default set of optimisations, and for most icons you can accept them as they are. Three are worth understanding because they have a visible effect or a trade-off.

The one to handle with care is precision. Coordinates are where most of an icon's bytes live, so rounding them is where most of the saving comes from, but round too aggressively and a curve that relied on fine positioning can shift. For ordinary UI icons, three decimal places is invisible to the eye and still cuts the file hard. For a detailed illustration, check the result at full size before you commit.

Manual wins you can do by hand

An optimiser handles the heavy lifting, but a few habits keep files lean from the start and are easy to apply yourself:

• Use currentColor for single-colour icons. Set fill="currentColor" and the icon inherits the text colour around it, so you ship one file instead of a copy per colour. The recolouring guide covers this in full.
• Drop fixed width and height, keep the viewBox. The viewBox defines the coordinate space; width and height just pin a default size you can set in CSS instead.
• Flatten before export. In your design tool, merge shapes, expand strokes you do not need to keep editable, and delete hidden layers before you export, not after.
• Avoid embedded raster images. A PNG pasted inside an SVG is base64-encoded into the markup and can balloon the file to hundreds of kilobytes. If you see a long data:image/png string, the artwork is not really vector.

Compress on the server too

Cleaning the file and compressing the transfer are two different savings, and they stack. Because SVG is text, it gzips beautifully, frequently by seventy to eighty per cent. Most hosts enable gzip or the newer Brotli automatically, so an already-optimised 800-byte icon might travel as 250 bytes over the wire.

You do not normally configure this per file. It is a server setting that applies to text types including image/svg+xml. If you manage your own server config, make sure SVG is included in the list of compressed MIME types. If you are on shared hosting, it is almost certainly already handled. The point to remember is that server compression is not a substitute for cleaning the file: a bloated SVG gzips to a smaller bloated SVG, so do both.

Inline, sprite or file?

How you deliver an icon affects total weight as much as the icon itself. There is no single right answer, only trade-offs:

• Separate files are simple and cache well. Best when icons are large or used on few pages. The browser fetches each one, so dozens of tiny requests can add up.
• Inline SVG drops the markup straight into the HTML. No extra request, and you can style it with CSS, but it is not cached separately and repeats if you reuse the same icon many times.
• An SVG sprite bundles many icons into one file and references them with <use>. One request, cached once, and each icon costs only a short reference. This is usually the most efficient option for a set used across a site.

For a handful of icons, separate optimised files are perfectly fine. For a UI that uses the same set on every page, a sprite is worth the small setup. The guide to using SVG icons walks through each delivery method in practice.

Common mistakes

• Removing the viewBox. It looks like dead weight and it is not. Strip it and the icon loses its ability to scale.
• Over-rounding coordinates. Chasing the last few bytes by cutting precision to one decimal place can warp curves. Stop at three for icons.
• Optimising once, then editing in a design tool again. Reopening and re-exporting re-adds the cruft. Optimise as the last step before the file ships, not in the middle.
• Forgetting accessibility. An aggressive clean can delete a meaningful <title>. Decide what each icon needs before you strip everything.
• Shipping design-tool exports straight to production. The single most common cause of heavy icons is simply never running them through an optimiser at all.

Frequently asked questions

Start from clean source files: browse the library, learn the ways to use an SVG icon, or make your icons accessible before you ship them.