Open the SVG that Illustrator just exported. Half the file is XML namespaces you never use, layer metadata for Photoshop round-trips, GUID comments, decimal coordinates with eight digits of precision, and an XMP block describing the fonts in the file even though no text remains. Strip all of it and you typically cut the file in half — sometimes by 80% — without changing a single rendered pixel. That gap between "what the design tool exported" and "what the browser actually needs to render" is what this optimizer harvests.
Optimization runs entirely in your browser through regex-based transforms, so the SVG payload never touches a server. Useful for proprietary brand assets you do not want to paste into a third-party tool.
How to use
- Paste the SVG source— copy from the file or directly from a design tool's SVG export.
- Click Optimize — the regex pipeline strips redundant declarations and shortens numeric precision.
- Compare bytes — original vs. optimized size and percent saved are shown side by side.
- Preview the result — render the optimized SVG to confirm nothing visual changed.
- Copy or download — paste into your code base or save as a
.svg file.
What gets stripped (and why)
- XML declaration / DOCTYPE. The browser does not need
<?xml ...?> or <!DOCTYPE svg ...> to parse inline SVG. Pure overhead. - Editor namespaces.
xmlns:sketch, xmlns:inkscape, xmlns:figma, xmlns:adobe and the attributes inside them only matter for round-tripping back into the design tool. - Comments and metadata.
<metadata>, <title> (when not needed for accessibility), and HTML comments add bytes without affecting rendering. - Empty groups and unused defs. Many exports wrap every shape in a
<g> with a single child or define gradients that are not referenced anywhere. - Decimal precision. A coordinate of
14.123456789 renders identically to 14.12 on any practical zoom level. Drop the extra digits to save a few bytes per number. - Default attribute values.
fill="black", stroke-width="1" and similar defaults can be removed because the SVG spec already implies them.
Preserve the viewBox (do not strip width / height carelessly)
The viewBox attribute defines the coordinate system the SVG paints into; removing it locks the SVG to whatever pixel size happens to be inlined and breaks CSS resizing. Aggressive SVGO presets sometimes strip width and height, which is usually safe if the viewBox remains; the browser then sizes from CSS. But never the other way around — without a viewBox the SVG will not scale.
Embedded vs linked SVG
Three common ways to include SVG, each with different optimization stakes:
- Inline in HTML / JSX. Best for small icons that need CSS styling (
currentColor, hover states) and accessibility hooks. Inflates the HTML payload, so optimization matters most here. - External
<img src="icon.svg">. Cached by URL, can be lazy-loaded, but scripts inside the SVG are sandboxed and CSS cannot reach into the SVG. Single request per icon. - SVG sprite +
<use href="#id">. All icons in one symbol-based sprite file, referenced by ID. One HTTP request, full styling control, scales to dozens of icons elegantly.
Accessibility — keep these in
An SVG without <title>renders for sighted users but is invisible to screen readers as anything other than "graphic." For any SVG that conveys meaning (logos with brand names, icons that label actions), preserve a <title> with descriptive text, set role="img" on the <svg>, and reference the title with aria-labelledby. Decorative SVGs should set aria-hidden="true" so they are skipped entirely. Stripping these unconditionally hurts accessibility — check your design intent first.
Security — SVG XSS
SVG is XML and can contain <script>, inline event handlers like onload, <foreignObject> hosting HTML, and embedded CSS with url() calls. Any of these execute when the SVG is rendered inline in a same-origin document. Never inline user-uploaded SVG without sanitizing — DOMPurify with the SVG profile is the standard tool. The optimizer here removes obvious metadata but is not a security sanitizer. For untrusted SVG, sanitize first, then optimize.
Comparison with SVGO and other tools
- SVGO. Full-featured Node-based optimizer with ~40 configurable plugins. Best quality but requires a build step. Used by Next.js, Astro, most design tools.
- This tool (regex-based). No dependencies, runs in the browser, covers the 80% of cases that account for most byte savings (metadata, comments, precision). Smaller wins than SVGO but instant, private, zero setup.
- SVGOMG. Web UI for SVGO. Same quality as SVGO with sliders for each plugin. Still uploads (well, runs the WASM build of SVGO in-browser, so privacy is preserved).
- Design tool exports.Modern Figma / Sketch / Illustrator have "optimize SVG on export" flags. Worth enabling, but they still leave metadata behind that a dedicated optimizer strips.
Performance and SEO notes
Inline SVG sits in the critical path because it ships inside the HTML. A 40 KB icon set in your <header> directly impacts Time To First Byte and First Contentful Paint. Optimization typically halves the SVG bytes; for an icon-heavy app the savings compound across every page load. For SEO, Google can index SVG content and follow links inside it — keep semantic <title> tags so the alt text travels with the asset.
Frequently asked questions
Q: Will optimization break my SVG?
The transforms here only remove non-visual metadata and redundant defaults — not paths, fills, strokes, or anything that affects rendering. Always preview the optimized SVG to verify. If you have custom namespaces (e.g. icon names used by your own pipeline), those will be stripped; preserve them by skipping optimization for those files or whitelist the namespace.
Q: How much size reduction can I expect?
Highly dependent on source. Figma / Sketch / Illustrator exports often shrink 30–60%. Hand-written SVGs that already omit metadata may see <5%. Files with long XMP metadata blocks (saved from Photoshop) can drop 80%+.
Q: Does this tool use SVGO?
No. It uses a lightweight regex pipeline that runs entirely in your browser with zero dependencies. The trade-off is smaller savings than full SVGO but no upload, no build step, and instant results. For maximum compression on production assets, plug SVGO into your build (Next.js / Vite / Webpack loaders all support it).
Q: Is the SVG data uploaded anywhere?
No. All transforms run in-browser. The SVG never leaves your machine — confirm in DevTools Network. Safe to use with proprietary brand assets.
Q: Why does the optimizer skip my custom data-attributes?
The optimizer preserves anything that might be functionally meaningful and only strips the well-known editor namespaces. If you want a customdata-* attribute removed, run a separate pass or extend the pipeline. Leaving it in is the conservative default.
Q: Is optimization the same as sanitization?
No. Optimization shrinks bytes; sanitization removes executable content like <script>, inline event handlers, and <foreignObject>. For untrusted SVG, sanitize with DOMPurify first, then optimize. Never inline user-uploaded SVG without sanitization, even after running it through this tool.