Choose an SVG
Add one SVG file within the displayed size limit.
Optimize an SVG locally by removing comments, editor metadata, and safe whitespace while inspecting the source and comparing file sizes.
Three simple steps, with your content kept on your device.
Add one SVG file within the displayed size limit.
Review source text and remove only conservative, safe-to-remove content.
Use the optimized source or save a new SVG file locally.
Fast, focused, and made to be clear on every screen.
Removes comments, editor metadata, and safe structural whitespace.
Rejects scripts, active elements, external references, and malformed XML.
Compare exact UTF-8 byte sizes for the original and optimized source.
Paste your markup or open an SVG file, and the tool parses it, strips the parts that do not affect rendering, and reports the before and after sizes. You can inspect the optimized source directly and copy or download it when the result looks right.
Everything happens locally. The SVG is parsed and re-serialized by JavaScript in the current tab, so logos, icons, and illustrations that are not public yet never leave your device.
To minify SVG output as far as this tool safely can, run it once and compare the size figures. Because the process is conservative by design, the reduction comes from genuinely redundant content rather than from risky rewrites.
Comments go first — they are frequently the largest single waste in an exported file, especially when a design tool stamps a generator banner into every export.
Editor metadata is next. Illustrator, Figma, Sketch, and Inkscape all embed private namespaces, layer names, and internal identifiers that mean nothing to a browser. Removing them can cut a file substantially without changing a single pixel.
Finally, whitespace-only nodes between elements are dropped. Pretty-printed markup carries an indentation string between every tag, which adds up quickly in a file with hundreds of paths.
Rendering attributes are left alone. Fills, strokes, transforms, gradients, clip paths, and the viewBox all survive, because changing any of them risks changing how the graphic looks.
Structure is preserved too. Groups, defs, and symbols stay in place rather than being flattened, so an SVG that is referenced by id from elsewhere keeps working after optimization.
This is a deliberate trade-off. Aggressive optimizers squeeze out more bytes by rewriting path data and merging elements, and they occasionally break a graphic in the process. Here the priority is that the output still renders exactly as the input did.
SVGs are often inlined directly into HTML or CSS, which means every wasted byte is downloaded on every page view and cannot be cached separately. A bloated icon set inflates the initial payload of an entire site.
Metadata is also a quiet privacy problem. Exported files can carry the original file path, the document name, and the layer names an internal team used, all of which ship to anyone who views the source. To clean SVG file exports before publishing is as much about not leaking context as it is about size.
Smaller files are easier to work with in version control too. Stripping generator noise means a diff shows what actually changed in the artwork rather than a churn of editor attributes.
SVG is XML, and XML can carry scripts, external references, and event handlers. That makes an SVG from an unknown source genuinely risky to open — it is closer to an HTML file than to a PNG.
This tool treats every input as untrusted data. Active and external content is rejected rather than passed through, and the preview renders from a validated Blob image instead of injecting the markup into the page, so a hostile file cannot execute in the context of the site.
That does mean an SVG relying on embedded scripts for animation will be refused. For static graphics — which is nearly all of them — the restriction has no practical cost.
Because SVG is XML, the XML Formatter is useful for reading a minified file when you need to edit it by hand.
The Image Converter turns an optimized SVG into a raster PNG or JPG for contexts that cannot use vectors, and the Image Metadata Remover handles the same metadata problem for photographs.
All of these tools run entirely in the browser, so a full optimize-inspect-convert pass never uploads your artwork.
No. The workflow is intentionally conservative, but XML serialization and whitespace cleanup cannot guarantee pixel-perfect equivalence for every SVG.
Comments, metadata elements, common editor-only attributes, and whitespace-only nodes between elements are removed. Rendering attributes and SVG structure are preserved.
No. SVG input is treated as untrusted data. Active or external content is rejected, and the preview uses a validated Blob image rather than injecting source into the page.