What an SVG Optimizer Actually Changes (and What to Hand-Edit Instead)
An SVG optimizer is a blunt instrument. It removes what it cannot identify as meaningful, which is usually right and occasionally catastrophic. Knowing which is which, before you run it, is the difference between a 60 percent size reduction and an icon that renders blank in production.
An SVG exported from a design tool is usually two to five times larger than it needs to be. It carries metadata, editor namespaces, hidden layers, redundant group nesting, and coordinates with five decimal places. An optimizer removes most of that automatically. The question is which removals are always safe, which depend on how you use the SVG, and which you should never automate.
What is safe to strip
Editor metadata is the first to go. The id="Layer_1" attributes, the xmlns namespaces for Illustrator and Sketch, the <metadata> block, and the inkscape and sodipodi namespaces do nothing in a browser. Removing them is always safe and often cuts the file size in half on its own.
Comments and formatting whitespace are also safe to remove. SVG supports whitespace for readability, but a production SVG does not need to be readable. Minifying the markup, removing indentation and line breaks, is a free win.
Redundant default attributes are the third safe target. fill="black" on an element that inherits black anyway, stroke="none" when stroke is already none, and font-family on a path with no text all add bytes without changing the render. A good optimizer drops them.
Where optimization starts to break things
Path simplification is where optimizers earn their keep and where they cause the most subtle damage. Rounding coordinates from 12.34567 to 12.35 is usually invisible. Rounding to 12 can shift a curve enough to look wrong at large sizes. Most optimizers let you control the precision, and the default is a compromise. If an icon looks slightly off after optimization, coordinate rounding is the first thing to check, not the path commands themselves.
Merging paths is more dangerous. Combining multiple <path> elements into one saves bytes, but it also flattens the structure. If you later need to animate one path independently, or recolor one segment, the merge has removed that ability. Path merging is a one-way operation. Only do it when you are sure you will not need the individual paths.
Gradient and filter optimization is the most common cause of a blank render. Some optimizers simplify gradient stops or merge filters in ways that change the output, and a few drop a filter entirely if they think it has no effect. If a graphic with a drop shadow or a blur renders flat after optimization, disable filter and gradient optimization and try again.
Accessibility is not optional
An SVG used as a meaningful graphic needs a <title> and, for complex graphics, a <desc>. An SVG used as decoration needs aria-hidden="true" or role="img" with an empty label. Optimizers do not add these. They will happily strip an existing <title> if you configure them aggressively, on the assumption that it is unused.
The rule is to set accessibility attributes after optimization, not before, so the optimizer cannot remove them. For an icon set, this is also where you decide whether each icon is decorative, in which case it inherits its label from the surrounding text, or meaningful, in which case it needs its own.
Turning an SVG into an icon component
A clean SVG is the input to an icon component. The component wraps the SVG, accepts a size and a color, and makes the path reusable. The mechanical part is extracting the d attribute from the path and dropping it into a component template.
The part that is easy to miss is currentColor. An icon that should inherit text color needs fill="currentColor" or stroke="currentColor", not a hardcoded color. If the source SVG has fill="#000", the component will render black even when the surrounding text is white. Replacing hardcoded colors with currentColor before building the component saves you from an icon set that does not adapt to dark mode.
The SVG tool on this site generates React and Vue component boilerplate from a path, so you do not have to copy the d string by hand. The output is a starting point, not a finished component. You still need to decide on the prop types, the default size, and whether the icon is controlled or uncontrolled.
Path animation, and why it is harder than it looks
Animating an SVG path, the drawing-in effect where the line appears to draw itself, uses stroke-dasharray and stroke-dashoffset. The technique is well known but has two gotchas. First, it only works on stroked paths. A filled path with no stroke has nothing to dash, so the animation does nothing. Second, the dash length has to match the path length, which you usually compute in JavaScript with getTotalLength().
A CSS template can give you the keyframes, but the length is path-specific. If you swap one path for another, the animation breaks unless you recompute. Treat path animation as something that needs a tiny bit of JavaScript to set the length, not as a pure CSS effect.
When to hand-edit instead
Optimizers are good at removing things. They are bad at restructuring. If an SVG has twenty paths that should be one, or one path that should be three for independent animation, an optimizer will not help. If a group is transformed in a way that breaks the layout, the optimizer will preserve the break.
Hand-edit is the right call when you need to restructure, when you need to add semantic groups for animation, or when the optimizer output does not render correctly and you do not want to disable features one by one. The optimizer gets you 80 percent of the size reduction in one pass. The last 20 percent, the part that requires judgment, is still a human job.
Primary references
Standards and official documentation used to check the technical details in this guide.
Optimize SVG and extract path data locally
The SVG tool on this site cleans markup, extracts path data, and generates React or Vue icon component boilerplate with CSS path animation templates, all in the browser. Useful for shrinking hand-exported files and for building icon sets without copy-pasting path strings by hand.
Open the SVG toolRelated guides
Continue with practical guides from the same topic area.
What Actually Belongs in a Production Dockerfile for Node (and What Doesn't)
Most Node Dockerfiles in the wild copy node_modules into the image, run as root, and ship a 900 MB layer. A short guide to the few decisions that matter: base image, multi-stage builds, layer caching for dependencies, the NODE_ENV trap, and why your docker-compose should not mirror production.
Catching Missing Translation Keys and Interpolation Mismatches Before Users Do
A missing translation key renders the raw key path to users, and a mismatched interpolation parameter renders an empty string or a crash. Both are easy to miss in review because the developer's locale always has every key. A guide to comparing locale JSON files, finding missing keys, and catching parameter mismatches before they ship.
Mock Data That Actually Exercises Your UI (Not Just Fills It)
Most mock data is ten copies of the same row with a different id. It fills the page and tests nothing. A guide to generating mock data that exercises layout edge cases, long names, missing fields, empty states, and the date and number formats that break formatting code, with field inference so a sample JSON becomes a realistic dataset in one step.