How to reduce SVG file size: what makes it large

An SVG is a text file, so its size is the amount of text in it. Five things account for most oversized SVG files: a picture embedded in the file, far more points than the shapes need, numbers written with too many decimal places, data left behind by the editor, and the same shape written out many times. The last three can be fixed without touching the drawing, and the SVG optimizer does most of that in one step. The first two need a decision from you.

Find the cause first

Open the file in a text editor, or in the SVG viewer, and look for these.

What you see in the code	Cause	Section
<image followed by data:image/png;base64, and a long run of letters	A picture stored inside the file	1
Path data that runs on for screens, thousands of small steps	A traced picture, or shapes with too many points	2
Numbers such as 47.262188 and 120.00000	Long decimals	3
<metadata>, names with inkscape: or sodipodi:, comments, an <?xml line	Editor data	4
The same <path> or <circle> again and again, or the same style="..." on every element	Repetition	5

1. A picture inside the file

An SVG can hold a PNG or JPG in an <image> element, written out as base64 text. That text is a third larger than the picture itself, because base64 spends four characters on every three bytes. In a test for this guide, 30,000 bytes of image data became a 40,131 byte SVG.

No optimiser can do much about it. The picture is already compressed, and the shapes around it are a rounding error beside it. The choices are:

• If the picture should not be there, delete it. Exports often carry a stray photograph or a rasterised effect: a shadow, a blur or a texture that the editor turned into pixels.
• If the artwork is a picture in an SVG wrapper, it is a picture and not a vector file. Use the PNG or JPG directly, or trace it into shapes with Image to SVG.
• If the picture is needed, make it smaller before embedding it: fewer pixels, or JPG in place of PNG for a photograph. For a web page, link to the picture as a separate file so that the browser can cache it.

2. Too many points

A hand-drawn curve needs a handful of points. The same curve from an automatic trace can have hundreds, and every point is a pair of numbers in the file. Traced photographs, scanned drawings and maps are the usual sources, and such files can run to megabytes.

Reducing points changes the shapes slightly, so it is done in a vector editor where you can watch the result:

• Inkscape: select the paths and choose Path, Simplify, which removes some of the points.
• Before tracing: trace with as few colours as the artwork has, and raise the setting that ignores small specks. Inkscape Trace Bitmap covers the settings.
• Remove what cannot be seen: shapes hidden behind other shapes, objects off the page, and specks too small to notice.

3. Long decimals

Editors often write coordinates with six or more decimal places. On a drawing 1,000 units wide, the sixth decimal place is a millionth of a unit, and no screen or machine can show it.

Rounding is the largest safe saving in most files. In a test, a path of 500 points written with six decimal places was 11,453 bytes. With two decimal places it was 7,453 bytes, 35% smaller.

How many places to keep depends on the size of the viewBox, because the numbers are in its units. Two places suit a drawing a few hundred to a thousand units wide. A 24 unit icon needs three. The optimiser suggests a number from the viewBox and shows the two pictures side by side, so a cut that goes too far is visible at once.

4. Editor data

A file saved from a drawing program carries things only that program reads: its own settings, layer names, guides, a metadata block, comments, and namespace declarations for all of it. None of it is drawn. Removing it is safe unless you mean to open the file in the same editor and want its layers back.

The optimiser’s sample is a star in a ring, saved the way a vector editor saves it. The numbers for that file:

	Bytes	After gzip
As saved by the editor	2,589	947
Editor data removed, nothing else	1,606
Fully optimised, two decimal places	764	394

The file is 70% smaller on disk, and the picture is identical pixel for pixel.

5. Repetition

The same attributes on every shape. Two hundred circles that each say fill="teal" can say it once on a group around them:

<g fill="teal">
  <circle cx="5" cy="5" r="3"/>
  <circle cx="15" cy="5" r="3"/>
</g>

The same shape many times. Define it once and draw copies with <use>: see SVG g and use. When the copies sit on a regular grid, a <pattern> replaces them all with a single tile: see SVG pattern.

Measured on a grid of 200 dots:

Written as	Bytes	After gzip
200 circles, each with its own fill	8,738	625
200 circles in a group that sets fill	6,357	600
One circle and 200 <use> elements	6,185	606
One <pattern>	248	193

The gzip column carries a lesson. Compression is good at repetition, so tidying repeated attributes saves little once the file is compressed. Removing the repetition altogether, as the pattern does, saves a great deal either way.

Text converted to outlines. Lettering turned into paths costs a path for every letter. Real <text> is a few bytes, but depends on the font being present where the file is opened. For a cutting machine the outlines are needed. For a web page, real text is smaller, and it can be selected, searched and read aloud by a screen reader. SVG text explains the trade.

Export settings that keep files small

Illustrator. Use File, Export, Export As and not Save As. In the SVG options set Decimal to 2 and switch Minify on. In Save As, the option Preserve Illustrator Editing Capabilities embeds an Illustrator file inside the SVG, which makes it larger. Exporting SVG from Illustrator goes through every option.

Inkscape. In File, Save As, choose Plain SVG. The Inkscape SVG type keeps the program’s own editing data. Either can then go through the optimiser to shorten the numbers.

Compress it on the server

Text compresses well. A web server that sends SVG with gzip or Brotli compression cuts the transfer size without changing the file: the editor’s file above goes from 2,589 bytes to 947. Not every server does this for SVG until it is told to: nginx, for one, compresses only HTML unless other types are listed in its gzip_types setting. To check, look at the response headers in the browser’s network panel: content-encoding should say gzip or br.

Optimising still pays after compression, though by less: the sample above goes from 947 to 394 bytes over the wire, 58% smaller, against 70% on disk.

An .svgz file is an SVG that has been gzipped in advance. Is SVG lossy or lossless explains when that is useful.

Tools

• In the browser: the SVG optimizer removes editor data, comments, unused definitions and white space, and shortens numbers and colours. It shows the size before and after and compares the two pictures pixel by pixel. The file is not uploaded.
• On the command line: SVGO is a Node.js program for the same job, handy for a whole folder of files or a build step:

npm install -g svgo
svgo drawing.svg -o drawing.min.svg

With its default settings, SVGO 4.1 brought the sample above to 700 bytes. It goes further than the optimiser on this site by rewriting path commands and merging paths, which saves a little more and now and then changes the picture, so look at the result.

What not to do

• Do not round to no decimal places on a small drawing. Curves turn into visible corners. Compare before and after.
• Do not remove the viewBox to save a few bytes. Without it the SVG cannot scale: see SVG viewBox explained.
• Do not strip ids from a file whose ids are used from outside, by a page’s CSS or scripts, or by <use> elements in other files.
• Do not optimise the only copy. Keep the editor’s file as the original and treat the small one as an export.

Questions

Why is my SVG bigger than the PNG? Because the artwork is too detailed for shapes to describe cheaply, as a traced photograph is. A photograph belongs in a JPG or PNG. SVG vs PNG compares the two.

Does a smaller file change how it looks? Removing editor data, comments and white space cannot. Rounding numbers can if it is taken too far, and simplifying paths always changes them a little.

Does file size matter for a cutting machine? The number of points matters more than the bytes, because the machine has to follow every one. Editor data and long decimals make no difference to the cut.