How to separate an SVG into color layers

What color separation actually means

An SVG is a pile of shapes, and each shape carries a paint. A logo that reads as three colors is usually not three objects. It is forty or four hundred objects that happen to share three fill values, scattered across groups, wrapped in transforms, and sometimes painted by a stylesheet rather than an attribute.

Color separation means pulling that pile apart along color lines. Every shape painted red goes in one file. Every shape painted navy goes in another. Each file keeps the original canvas, so when you stack them back up you get the artwork you started with, in register, pixel for pixel.

Who needs it and why

This is one of those operations that sounds niche until you hit it, and then it blocks your whole afternoon.

Screen printing

Every ink needs its own screen, and every screen needs its own film positive. If your artwork is spot color vector, a color separation is literally the deliverable. One file per ink, all at the same size and position.

Vinyl cutting and heat transfer

Cricut, Silhouette, Cameo and Roland plotters all cut one sheet of one color at a time. Importing a three color design as three files means each color lands on its own mat with the registration intact.

Laser cutting and engraving

Most laser software maps color to operation. Cut on red, score on blue, engrave on black. Clean per color files remove the guesswork of assigning operations shape by shape.

Editing and recoloring

Trying to recolor a traced illustration by selecting shapes one at a time is misery. Once each color is a single path you can change a brand color across an entire illustration by editing one attribute.

Animation and web handoff

Animating a logo is far simpler when each color is one addressable element instead of ninety siblings. Fewer elements also means less for the browser to lay out and paint.

Embroidery and print prep

Digitizing software works from clean shape boundaries. Merged, single path color regions convert far more predictably than hundreds of overlapping slivers left behind by an auto trace.

Separating is not the same as flattening

This is the distinction most tools blur, and it is the one that decides whether the output is actually usable.

Separating gives you a file containing only the red shapes. There might still be four hundred of them, each with its own transform, sitting in the same nest of groups they came from.

Flattening takes those four hundred shapes and merges them into one path element. The transforms get baked into the coordinates, every subpath is concatenated, and one color becomes one object you can select with a single click.

The five step walkthrough

1. Drop the file on the page. Or paste the raw markup. Nothing is uploaded anywhere, the parsing happens in your browser.
2. Read the layer list. Every color found in the artwork appears with a swatch, a hex value and a shape count. Click the eye to hide a color, click the row to isolate it.
3. Merge the near duplicates. Drag the tolerance slider until colors that differ only by a rounding error collapse together.
4. Choose your output shape. Leave flattening on for one path per color. Decide whether strokes get their own layer or stay with their fill.
5. Download. One layer at a time, all layers as a zip, a single layered file with one group per color, or a fully flattened file.

Merging colors that only look identical

Open a traced or exported illustration and you will often find that what your eye reads as one red is actually #ff0044, #ff0043 and rgb(255, 0, 68). Different strings, same ink. Left alone, that is three layers and three screens for one color.

The tolerance slider fixes this, but it does not compare hex codes. It converts every color into OKLab, a perceptual color space where the distance between two values matches how different they actually look to a human eye. A tolerance of 2 catches export rounding. A tolerance of around 10 starts grouping shades that a printer would treat as one ink anyway.

Making the output smaller without losing anything

Files that come out of a tracing tool or a design app carry a lot of freight that has nothing to do with what you see. The optimizer strips it, and it is careful to only remove things that cannot change a single pixel:

• Comments, <metadata> blocks and editor namespaces from Inkscape, Illustrator, Figma, Sketch and friends
• Definitions in <defs> that nothing in the layer actually references
• Whitespace between tags, left intact around <text> where it is meaningful
• Six digit hex values that can be written in three
• Path data rewritten in a shorter but numerically identical form: relative or absolute per segment, whichever is fewer characters, horizontal and vertical shorthand, mirrored curve shorthand, redundant separators and leading zeros dropped

On a 30MB test illustration the combination of flattening and optimizing brought the output to 20.4MB, about a third smaller, with the geometry untouched. There is also a precision control if you want to trade decimal places for bytes, which is the one setting here that can technically alter geometry, so it defaults to a safe value derived from the viewBox.

Setting	What it changes	Safe to leave on
Merge similar colors	How many layers you get	Yes, start at 0 and raise it
Split strokes	Outlines become their own layer	Yes
Flatten each color	One path per color, paint order in combined files	Yes for cutting and printing
Optimize output size	Markup only, never geometry	Yes
Precision	Decimal places in coordinates	Auto, unless you know your tolerance

Why huge files do not freeze the page

Most browser based SVG tools parse the file into a DOM and then ask the browser to compute a style for every element. That is fine for a 40KB icon. On a 30MB map export with 85,000 shapes it means minutes of waiting and hundreds of megabytes of memory, if the tab survives at all.

This tool never builds a DOM. The artwork stays as a single string. One streaming pass records the byte range of every element along with its resolved fill and stroke into flat typed arrays, resolving the cascade by hand instead of asking the browser. Every export is then produced by slicing the original string, so the cost of a layer is proportional to the shapes that layer keeps, not to the size of the file.

Measured on a synthetic 30MB file with roughly 85,000 shapes: parsing takes about 98 milliseconds in a 143MB heap, clustering the colors takes about 20 milliseconds, and producing all 25 layers plus the zip takes about three seconds. A file with 60,000 distinct colors still groups in about 200 milliseconds, because color clustering runs on a spatial hash rather than comparing every color to every other color.

What is deliberately left alone

A flattening tool that quietly changes your artwork is worse than no tool. Anything that cannot be merged without altering the result is copied through in its original form instead:

• Gradients, patterns and embedded images go into a single leftovers layer, untouched
• Clipped, masked and filtered shapes keep their structure, since baking them into a path would change the render
• Partly transparent shapes stay separate, because merging them would double the overlap density
• Text stays as text, including multi colored text where individual tspan runs land in different layers
• Shapes under a stretched or skewed transform keep their element when they carry a stroke, because no single stroke width can describe a non uniform scale
• Markers and non scaling strokes are excluded from merging for the same reason

Because of that, the union of all exported layers always reproduces the file you started with.

Questions people actually ask