SVG optimizer. In-browser, lossless.
Paste SVG or drop a file. We strip comments, editor metadata (Inkscape, Adobe, Sketch), redundant default attributes, and round decimals. Toggle each cleanup pass. Live preview both sides plus a savings percentage.
Paste SVG or drop a file. The optimizer strips comments, editor metadata, redundant attributes, and rounds decimals. Toggle each pass independently. Live preview both sides plus byte-savings percentage. Pure vanilla — no upload.
// optimized SVG appears here
Privacy: optimization happens in your browser. Nothing is sent or logged.
Six passes. Each toggleable.
Strip XML declaration. The <?xml version='1.0'?> line tells parsers this is an XML document. Required for standalone .svg files served as image/svg+xml. Optional — and pure overhead — when embedding inline in HTML, where the surrounding HTML already declares the document type. Strip when inlining; keep for standalone files.
Strip comments. Authoring tools and developers often add HTML/XML comments (<!-- ... -->) explaining what each section does. Useful at edit time, dead weight in the shipped file. Strip safely — comments never render.
Strip editor metadata. The biggest savings on SVGs from Inkscape, Illustrator, or Sketch. Each editor stores its own state — pencil tool position, layer names, page bounds, undo history pointers — in custom XML namespaces (sodipodi:, inkscape:, i:, sketch:). The browser ignores all of it. Stripping makes the SVG harder to round-trip back into the editor with full edit history but doesn't change rendering.
Remove default attributes. The SVG spec defines default values for many attributes. stroke-width="1" is the default. opacity="1" is the default. Editors often write these explicitly anyway. Stripping is safe unless your CSS overrides them — in which case the inline value was winning over the CSS, and removing it lets the CSS take effect (usually what you wanted).
Round decimals. Editors and auto-tracers often write coordinates with 9-15 decimal places (cx="50.123456789") when the rendered pixel difference past 2-3 decimals is invisible. Rounding to 3 decimals is safe for almost all visual output. Bumping down to 1 decimal is aggressive and may cause visible jitter on detailed paths; keep at 3 unless you've tested the specific path.
Collapse whitespace. Pretty-printed SVG has indentation, line breaks, and spaces between tags for human readability. Browsers don't care. Collapsing whitespace between tags (but preserving meaningful whitespace inside text content) saves bytes without changing rendering.
Four jobs this tool covers.
Job 1: Inline SVG icon cleanup. When dropping an SVG icon directly into HTML or a React component (<svg>...</svg> in the markup), the editor metadata and XML declaration become inline noise. Strip everything, paste the cleaned SVG. The resulting markup is small and reads cleanly in code review.
Job 2: Logo file optimization. Logo SVGs from a brand handover often arrive as 50-200KB Inkscape exports with full edit history embedded. Strip the metadata and you're typically down to 2-10KB. Pair with our Favicon Generator if you need to derive favicons from the cleaned logo.
Job 3: Pre-CDN audit. Before uploading a vector asset to your CDN or static-site directory, run it through here to confirm it's not carrying 80% editor cruft. Lighthouse and PageSpeed Insights flag oversized SVG files just like they flag oversized PNG/JPEG. Cleaner SVG → faster page → better Core Web Vitals.
Job 4: Audit a third-party icon set. When evaluating an icon library or a partner's vector assets, the byte-savings figure tells you about their export hygiene. A library where every icon strips by 70% is a library shipped without optimization. A library that's already <5% improvable is a sign of a careful maintainer. Useful filter for SaaS / API / partner due diligence.
Six questions users ask.
What does the optimizer actually strip?
Six classes of cruft. (1) Comments — XML comment blocks (denoted by the angle-bang-dash markers) that don't render. (2) Editor metadata — Inkscape's sodipodi: and inkscape: namespaces, Adobe Illustrator's i: namespace, Sketch's sketch: namespace, all of which carry editor state but no rendering information. (3) Redundant attribute defaults — fill='black', stroke-width='1', and other attributes whose value matches the SVG default. (4) XML declarations — the XML declaration line (the angle-bracketed processing instruction at the start) is required for standalone SVG files but redundant when embedding inline in HTML. (5) Whitespace between tags — collapses safely without changing rendering. (6) Decimal precision — coordinates and lengths get rounded to your chosen precision (default 3 decimals).
Is the optimization lossless?
Lossless for visual rendering. Editor metadata is technically information — losing it makes the SVG harder to round-trip back into Inkscape or Illustrator with full edit history. Decimal rounding is sub-pixel precision change; at 3 decimal places (the default) the visual result is indistinguishable from the source. Bumping precision down to 1 decimal will cause visible jitter in complex paths; at 2 decimals it's still safe for most use. Toggle precision based on whether you need to keep editing the file in a vector editor or just ship to the web.
How much does this typically save?
Depends entirely on the source. SVGs exported directly from Inkscape, Illustrator, or Figma typically lose 40-70% of bytes after optimization — most of that is editor metadata and verbose decimal precision. SVGs hand-written for the web are usually already small. Auto-traced SVGs (from raster images) can lose 80%+ because the precision tends to be much higher than visually useful. Run on a few of your icon set and you'll see the typical savings range for your source.
How is this different from SVGO?
SVGO is the Node-based industry-standard SVG optimizer with 30+ configurable plugins and far more aggressive optimization than what runs in a browser. For production build pipelines, use SVGO via CLI or as a build step (Webpack svgo-loader, Vite vite-plugin-svgr). This in-browser tool is for one-off optimization, ad-hoc audits, and learning what an optimizer actually changes. The cleanup we do covers the 80% common case; the remaining 20% is plugin-specific or context-dependent and only worth running through SVGO.
Will it break my SVG?
Each cleanup pass is toggled separately so you can isolate any breakage. The most common cause of broken output is removing default attributes when those defaults are being overridden by CSS. If your CSS sets stroke='red' but the SVG has stroke='black' inline, the inline black 'wins' over the CSS — removing the redundant inline attribute then lets the CSS take effect. Usually that's what you want. If your SVG breaks after optimization, toggle off 'remove default attributes' and try the other passes.
Is the SVG I paste sent anywhere?
No. Optimization happens entirely in your browser — pure vanilla JavaScript regex passes. The page is static HTML; the only network request is the initial page load. Safe for unpublished brand assets, internal icon sets, or any sensitive vector content.
Published · Last updated .