CruxDevCruxDev Tools Prompts
image Utility • Zero-Server Privacy • 100% Client-Side

SVG Optimizer

Safely optimize SVG files in-browser with a DOM parser — remove comments, metadata and editor artifacts, round decimals, and minify without corrupting paths, CDATA or styles.

Overview

Optimize SVG markup in your browser with a real XML parser, not a pile of regexes: strip generator comments, metadata blocks and editor-namespace attributes, drop empty groups, round over-precise decimals, and remove invisible whitespace - then see exactly how many bytes you saved and what changed. Paste, read the optimised output, copy it. No upload, no account, no waiting.

How It Works

Paste your SVG into the left pane. The optimised result appears immediately on the right with its byte count and the percentage saved relative to the original, shown in each pane's header, and a change list spelling out every pass that removed something: how many comments or processing instructions were deleted, how many metadata blocks and editor attributes were stripped, how many numeric values were rounded. Press Copy Optimized SVG to take the result. Output updates live as you edit the input, and a red banner appears instead of output if the input is not well-formed XML.

Step-by-Step Usage Guide

  1. Paste the SVG markup into the left editor.
  2. Read the optimised output, the saved-percentage figure and the change list.
  3. Check the preview in your project after pasting the result.
  4. Copy the optimized SVG.

Technical Specifications & Standards

The engine parses your markup with the browser's DOMParser in SVG mode and re-serialises the document tree, so the structure can never be broken by a pattern match: nested groups stay nested, CDATA sections inside <style> keep their exact bytes, inline style attributes and <text> content keep their internal whitespace, and attribute values that contain angle brackets survive with correct escaping. On top of that safe parse it performs a conservative set of passes: comments and processing instructions removed; <metadata> and editor-namespaced attributes (inkscape:, sodipodi: and friends, plus their xmlns declarations) stripped; groups with no children dropped; numeric attributes and path data rounded to three decimals; whitespace-only text nodes between elements removed while text inside <text>, <tspan>, <style>, <title> and <desc> is left untouched. What it deliberately does not do: merge paths, flatten groups or restructure path data - full SVGO-class restructuring trades safety for bytes. If the input is not well-formed XML, the tool refuses to touch it and returns the original with an error rather than emitting mangled markup. Byte counts are measured UTF-8 sizes of both strings, so the reported saving is measured, not estimated.

Targeted Use Cases

  • Shrinking icon SVGs before inlining them in HTML or a component library.
  • Cleaning up Illustrator or Inkscape exports that carry metadata and editor namespaces.
  • Reducing the payload of inline SVG backgrounds in CSS.
  • Removing tool-generated comments before committing an icon set.

Notes & Gotchas

  • Render-test the output after optimising, as with any minifier.
  • Trust the safety model: malformed XML is rejected, not half-cleaned - fix the source and re-run.
  • For complex illustrations, pair this with a structural optimiser such as SVGO for bigger gains.
  • Inline the result rather than serving it as a separate file when it is under a kilobyte.

Frequently Asked Questions

Is this the same as running SVGO?

No. It is a DOM-based cleaner: it strips comments, metadata, editor artifacts and empty groups, rounds decimals and removes invisible whitespace, but does not restructure paths or merge styles the way SVGO does. The tool is named accordingly.

Can it corrupt my SVG like regex minifiers can?

That failure mode is designed out. The document is parsed as XML and re-serialised, so nested groups, CDATA, inline styles and angle brackets in attribute values survive; if the input cannot be parsed, nothing is changed and you get an error instead.

Will optimisation change how my SVG looks?

Rounding is limited to three decimal places, which is visually lossless for virtually all artwork, and text content is never touched. As with any minifier, spot-check the rendering after compressing.

Are the byte counts accurate?

Yes. Both strings are measured in UTF-8 bytes, so the saved figure in the output header is a real measurement, not an estimate.