Which kind of too big do you have?
There are three readings of the same complaint, and they have different causes.
- Bytes. An upload form rejects the file, or a page with the SVG on it loads slowly. This is a file size problem.
- Inches. Design Space scales your design down, or warns that it will not fit. This is a document size problem, and the file itself may be tiny.
- Slowness. The software crawls and the machine takes forever to cut. This is a node count problem, and again the file can be small.
Most advice online assumes the first one and hands you a compressor, which is why people with the second problem keep searching.
An SVG is text, and text costs bytes
An SVG stores geometry as characters. Every point on every path is a pair of numbers written out in full, plus the letter that says what to do with them. File size therefore tracks how many points the file contains, not how large the picture looks on screen.
The clearest way to see that is to measure a real file. The before and after pair used on this site's home page for a detailed illustration is a 174 KB JPEG and a 588 KB SVG. The SVG holds 1,956 paths, and 526,601 of its 601,620 bytes are path coordinates, which is 88% of the file spent describing points and the few letters that join them up.
A much simpler logo from the same set behaves the same way at a smaller scale. 195 paths, 135 KB of file, and 124,803 of its 137,807 bytes are coordinates. Two files that differ in size by a factor of four are made of almost exactly the same stuff.
Why tracing produces so much text
A tracer decides how many points it needs to describe each edge. A logo with flat colour and hard edges needs a few hundred. A photograph has soft edges everywhere, so the tracer has to place a point wherever the colour changes, and in a photograph that is close to every pixel boundary.
This is the trade being made, and it is worth stating plainly. A traced photograph is large because the source genuinely contains a lot of small detail and the tracer was asked to keep it. If you want a small file out the other end, the fix is upstream: fewer colours, a smaller source, or a simpler picture to begin with.
It also means a traced file is often bigger than the image it came from, which surprises people. A 174 KB JPEG becoming a 588 KB SVG is normal for a detailed source, because the JPEG spends its bytes on a compressed grid of pixels while the SVG spends them on thousands of pairs of exact coordinates.
Where the bytes go, in order of what they are worth
Coordinate precision
The numbers are where the weight is, so precision looks like the obvious thing to attack. The dragon file holds 77,564 decimal numbers in its path data, and they are most of what the file is made of.
The surprise is how little is left to win in that file. Its numbers are already written compactly, because the tracer emits them that way: 76% carry two decimal places, 15% carry three, and the rest carry one. There is no padded precision sitting in there to remove.
That is worth measuring before you accept the usual claim that rounding coordinates halves a file. Rounding these three traced files to two decimals, and changing nothing else at all:
- the dragon illustration, 588 KB down to 574 KB, a cut of 2%.
- the logo, 135 KB down to 128 KB, about 5%.
- a sheet of small logo marks, 97 KB down to 93 KB, about 3%.
Rounding to three decimals saved nothing measurable on any of them. Rounding to one decimal is a different matter, because a number like 13.64 becomes 13.6 and every one of those 77,564 numbers loses a character. That took the dragon from 588 KB to 492 KB, the logo from 135 KB to 112 KB, and the marks from 97 KB to 82 KB, between 15% and 17% each time.
Whether one decimal is safe depends on how large the drawing is, and you can work that out from the file's own numbers. A document whose viewBox spans 1100 units and is drawn 11 inches wide gives one unit per hundredth of an inch, so 0.1 unit is a thousandth of an inch, far below what a blade can resolve. A small icon drawn 24 units to the inch is a different case. There, 0.1 unit is a visible share of a stroke, and two decimal places is the safer setting.
One more thing about these figures. They cover coordinate rounding on its own, applied to output that is already compact. A hand-built Illustrator file, with padding, whitespace and long numbers in it, has far more to give.
Editor metadata and scaffolding
Illustrator and Inkscape both write a great deal that has nothing to do with your artwork. Namespace declarations repeated on every element, a block of document history in the metadata, layer names, comments, empty groups, and definitions for gradients and clip paths that nothing references any more. On a hand-built file this can be most of the weight. On a traced file it is a small share, because the coordinates dwarf it.
An embedded bitmap
An SVG can hold a base64 encoded PNG or JPEG inside an image element. A file like that is a bitmap in a wrapper. Its size follows the bitmap, the paths inside it are trivial, and no amount of coordinate rounding will touch it.
You can spot one by opening the file and searching for data:image. If it is there, the file is not really a vector file yet, and the fix is to trace the bitmap rather than to optimise the wrapper. It is the same thing the PNG to SVG guide calls a wrapped bitmap.
Hidden and duplicated content
A hidden layer still contains geometry. A layer you switched off in Illustrator or Inkscape is present in the exported file with all its path data, because hidden and empty are different states. Delete them rather than hiding them, and delete empty groups while you are in there.
Text and fonts
Text left as text depends on the font being installed wherever the file is opened, which is why cut files usually convert text to outlines. Converting removes that dependency and can go either way on size. A short label converted to paths is smaller than the font data it replaces, and a long paragraph of text is usually smaller left as it is.
What actually shrinks the file
- Run an optimiser. SVGO is the standard and is available as a command line tool and wrapped by a lot of browser pages. svgcleaner is the main alternative. Both strip metadata, collapse groups, shorten commands and round coordinates.
- Set the precision deliberately rather than accepting whatever the default is. One or two decimal places is usually right for a cut file, and the measurements above tell you what each one costs.
- Delete hidden layers, empty groups and unused definitions in the editor first. An optimiser removes what is unreferenced, and it cannot know that a visible layer is unwanted.
- If the file came from a trace, fix the source instead. Fewer colours, a smaller source image, or a simpler picture means fewer points, and that is where the large reductions come from.
- If the file contains an embedded bitmap, trace it properly rather than optimising the wrapper.
Keep a copy before you optimise. A good optimiser is conservative, but every one of them can drop something it decided was unused, and you will not notice until you render the result.
Node count matters more than bytes
Bytes decide whether an upload is accepted. Nodes decide how the file feels to work with. The dragon above holds about 20,000 path commands, and the machine has to follow every one of them. More of them means a slower preview and a longer cut, and that experience gets described as the file being too big, even when the file is only a few hundred kilobytes.
The tracer's output is where this is decided, which means the honest answer to a slow cut is fewer points, and the way to fewer points is a simpler source image. Reducing a photograph to three or four flat colours before tracing does more for cutting time than anything you can do to the file afterwards.
If the file is going on a web page
Compress it on the way out. SVG is text, and text compresses well. Measured on the same three files: the dragon goes from 588 KB to 237 KB with gzip, the logo from 135 KB to 40 KB, and the logo marks from 97 KB to 27 KB. That is 60 to 72% off, for free, at the server.
With gzip or brotli switched on, a 200 KB SVG costs about 60 KB over the wire and the size on disk stops being the interesting number. For a web page, spend the effort on node count and rendering instead.
The other kind of too big: the mat
If Design Space is shrinking your design, the file is probably fine. Design Space works in inches on a mat, and an upload larger than 12 inches gets scaled down, because 12 inches is the mat. A file with no declared size is even more likely to land somewhere you did not intend.
An SVG declares how big it is with width and height attributes, and it describes its internal coordinate system with a viewBox. When width and height are bare numbers with no unit, they mean pixels, and the importer has to guess what that means in inches. When they carry a real unit, the file has a physical size and imports at it. A document meant to be 11 inches by 8.5 should say so directly: width="11in" height="8.5in" viewBox="0 0 1100 850".
The viewBox numbers do not have to be inches or millimetres. What matters is that their ratio matches the ratio of the width and height, because the viewBox is the internal grid and the width and height decide how large that grid is drawn. Any pair of numbers in the right ratio works.
If the design genuinely is larger than the mat, scale it in Design Space rather than in the file. It is a vector, so scaling costs nothing and cannot soften the edges. Size it where you can see the mat and the fit becomes obvious.
A cleanup order that works
- Work out which problem you have before changing anything.
- Open the file in a text editor and see roughly how much of it is coordinates rather than structure.
- Delete hidden layers, empty groups, stray specks and unused definitions in the editor.
- If the file contains
data:image, trace the bitmap instead of optimising the wrapper. - Run the optimiser at one or two decimal places of precision, on a copy rather than the original.
- Set width, height and viewBox if the mat size matters for the cut.
- Open the result once in Design Space before you cut anything with it.
Questions that come up
Why is my SVG bigger than the PNG or JPG it came from?
Because the two formats spend their bytes differently. A JPEG stores a compressed grid of pixels. An SVG stores thousands of pairs of exact coordinates. A detailed image needs a lot of coordinates, so the traced file can be several times the size of the source. The dragon above went from 174 KB to 588 KB, and even a simple flat logo went from 52 KB to 135 KB.
Does a smaller SVG cut faster?
Usually yes, because a smaller file nearly always means fewer nodes and the machine follows every node. The exception is a file that got smaller by losing an embedded bitmap, which does not change the cutting paths at all.
How big should an SVG be?
There is no rule, but the ranges are wide enough to be useful. A simple icon or logo should be a few kilobytes. A detailed illustrated logo is often 50 to 200 KB. A traced illustration in the hundreds of kilobytes is normal. A file over a few megabytes almost always contains an embedded bitmap, or a trace that followed noise.
Will optimising break my file?
It can, which is why you keep a copy. Optimisers remove anything they judge unused, and a definition referenced in a way the tool did not recognise goes with it. The render is usually identical and occasionally is not.
Is the too large message in Design Space about bytes?
Not usually. Design Space scales anything over 12 inches, so the message most people meet is about inches on the mat. There is also an upload size limit, and when you cross that one the error says so. Check which you got before you start compressing.
Do I need a compressor website for this?
You do not. Those pages are SVGO, or something like it, with an upload form in front, which means your file leaves your machine to do a job that runs locally in a fraction of a second. The tools are fine. It is worth knowing what is underneath them.