Free SVG Optimizer

How It Works

1. Paste or upload SVG: Enter SVG markup directly or upload a .svg file exported from Illustrator, Figma, or Sketch.
2. Configure optimisation passes: Choose which optimisations to apply, comment removal, metadata stripping, path simplification, and viewBox normalisation.
3. Optimise: The tool runs the selected passes and shows the file size reduction percentage.
4. Download or copy: Save the optimised SVG or copy the markup to paste into your code.

Why Optimise SVGs?

SVG files exported from design tools are filled with unnecessary data, editor metadata, inline style declarations with default values, empty groups, redundant transform attributes, and comments. This bloat increases file size without affecting the visual output. SVGO (the industry-standard SVG optimiser used here) can typically reduce SVG file size by 50–80% while maintaining pixel-perfect rendering. Smaller SVGs load faster, inline faster in HTML, and reduce bandwidth, especially important for icon systems with dozens of SVG files loaded per page.

Optimisations Applied

• Comments removed: editor and generator comments stripped
• Metadata removed: title, desc, and XMP metadata elements
• Empty groups collapsed: unnecessary <g> wrapper elements removed
• Paths simplified: redundant path commands merged and shortened
• Attributes cleaned: default values and presentation attributes removed
• ViewBox normalised: consistent coordinate system

A short history of SVG and SVGO

Scalable Vector Graphics started as a competition between two W3C proposals: Precision Graphics Markup Language (PGML) from Adobe, IBM, Netscape and Sun, and Vector Markup Language (VML) from Microsoft. Both were submitted in 1998; the W3C compromise became SVG, recommended as SVG 1.0 in September 2001. Internet Explorer notoriously refused to ship SVG support until IE9 (2011), while Firefox, Safari, and Opera supported it from the mid-2000s. SVG 1.1 appeared in 2003, with a Second Edition in 2011. SVG Tiny 1.2 targeted mobile devices in 2008. SVG 2 began drafting around 2016 but stalled; today it remains a Candidate Recommendation Draft (last touched in 2018), with browsers shipping pieces individually. Optimisation arrived later. SVGO was created by Kir Belevich (svg-go) and first published on GitHub in October 2012, written in JavaScript. It became the de facto standard, integrated into webpack-loader, Vite, Sketch, Figma export plugins, and the SVGOMG web UI by Jake Archibald (Chrome team) launched in 2015. SVGO 3 (released 2023) modernised the codebase. This tool implements a safe subset of SVGO's most impactful plugins, running entirely in your browser.

What an SVG optimiser actually does

• Decimal precision reduction. Illustrator exports paths with 6 decimal digits like M127.348293. Three decimals are visually identical for typical icon sizes; one or two often suffice. SVGO defaults to 3 decimals via the cleanupNumericValues plugin. Lower precision = smaller file.
• Collapse useless groups. Design tools wrap every operation in <g> elements; many become empty after simplification. The collapseGroups plugin merges single-child groups into their parent.
• Strip metadata. Illustrator stamps every export with <metadata>...</metadata> blocks containing XMP packets, Inkscape with sodipodi namespace attributes, Figma with editor IDs. None of this affects rendering. removeMetadata, removeEditorsNSData, and removeXMLProcInst handle these.
• Path command optimisation. Convert absolute coordinates to relative (often shorter), merge consecutive line segments (l 5,0 l 0,5 stays as two; L 5,0 L 5,5 becomes v 5), remove useless Z after z. The convertPathData plugin can save 30-50% on path strings.
• Default attribute removal. fill="black", stroke="none", stroke-width="1" are defaults; SVGO strips them. Combined with mergeStyles, this often cuts inline-styled exports in half.
• Colour shortening. #ffffff → #fff; rgb(255,255,255) → #fff; named colours (aliceblue) → hex if shorter. The convertColors plugin.
• Unused ID removal. Editor-generated IDs like id="path-7423" are usually never referenced. SVGO's cleanupIds removes orphaned IDs and minifies the rest to a, b, c...

Where SVG optimisation matters

• Icon systems. A page with 30 SVG icons at 2 KB each is 60 KB; optimised to 800 bytes each saves 36 KB. Heroicons, Lucide, Phosphor, Feather all ship pre-optimised SVGs; if you've extracted them from a design file, you need to do this yourself.
• Logos and brand assets. Logos shipped to clients are often 50-100 KB from Illustrator; optimised they're 5-10 KB. Same visual fidelity, lower bandwidth, faster page load. The Wikipedia logo SVG dropped from 39 KB to 11 KB after a single optimisation pass.
• Inline SVG in HTML. When you inline SVG (no extra HTTP request), every byte of the SVG bloats the HTML payload that blocks the browser parser. A 200-byte icon vs 2 KB matters for first paint timing.
• Data visualisation. D3.js, Observable, ECharts SVG output, and React-vis produce large SVGs with thousands of elements. A scatter plot with 5,000 points is easily 500 KB raw; optimised it can drop to 150 KB while remaining identical.
• Icon font generation. Tools like IcoMoon, Fontello, and Fontastic convert SVGs to icon fonts. Pre-optimising the source SVGs ensures cleaner font output and smaller font files.
• Print and PDF assets. Embedding SVG in PDF (via web-to-PDF tools like Puppeteer, wkhtmltopdf) means the SVG bloat ends up in the final PDF. Optimise first.
• Email-safe SVG. Many email clients (Outlook, some Gmail apps) don't render SVG at all; for those that do (Apple Mail, Gmail web), smaller inline SVG keeps emails under the 102 KB Gmail clipping threshold.

Optimisation mistakes that break SVGs

• Removing IDs that are referenced. SVGs often use <defs> with IDs that are referenced via url(#gradient-1) in fill or stroke. Aggressive ID removal breaks gradients, masks, clip paths, filters. Use a tool that tracks references, not blind regex.
• Removing width/height attributes blindly. Drops the natural aspect ratio. The result: <img src="icon.svg"> stretches to fit its container with no intrinsic size, causing CLS (Cumulative Layout Shift). Keep viewBox at minimum; preferably keep width/height too.
• Over-aggressive decimal reduction. Reducing to 0 decimals on small icons makes paths visibly jagged. 3 decimals is a safe default; go to 1 only for icons larger than 64×64 or where pixel-perfection isn't required.
• Removing xmlns when inlining. Standalone SVG files need xmlns="http://www.w3.org/2000/svg". Inlined SVG in HTML doesn't (HTML5 parser handles it), but if you might extract the SVG to a file later, keep the xmlns. Confusion here breaks Safari's SVG rendering.
• Replacing currentColor with hardcoded fill. fill="currentColor" is a powerful CSS hook: the icon inherits the text colour. Aggressive optimisers replace it with the computed value, breaking dark mode and themed icon systems.
• Merging paths that should stay separate. Some animations target specific path IDs; some accessibility tools rely on multiple <path> elements with individual <title> text. The mergePaths plugin destroys these. Disable it for animated or accessible SVGs.
• Stripping accessible <title> and <desc>. SVGs used as standalone images or in <img> tags need <title> for screen readers (similar to alt text). Aggressive metadata removal strips this. Either keep titles, or add aria-label on the inlined SVG element.

More frequently asked questions

How much can SVG optimisation actually save?

It depends heavily on the source. Adobe Illustrator exports often shrink by 60-80% on first pass, mostly from metadata, editor namespaces, and decimal-precision reduction. Figma exports are cleaner out of the box (typically 20-40% savings). Hand-written SVG by a developer? Often 5-15%, since there's not much to strip. The Wikipedia logo, an extreme case of Illustrator bloat, went from 39 KB to 11 KB. A typical 24×24 icon from Figma drops from 1.4 KB to 0.6 KB.

When should I inline SVG vs use it as an external file?

Inline (<svg>...</svg> in HTML) for small icons (under 2 KB), critical above-the-fold content, and anywhere you need CSS to style the SVG (e.g. currentColor, hover states, dark mode). External file (<img src="icon.svg"> or CSS background-image) for repeatedly-used identical icons (the browser caches), larger illustrations, content that doesn't need CSS theming. SVG sprite (single file with multiple <symbol> elements, referenced by <use>) was the icon-system pattern of 2014-2019, now largely superseded by inline-svg components in React/Vue/Svelte.

Are there security risks in unoptimised SVG?

Yes. SVG can embed <script> tags and onload, onclick event handlers; user-uploaded SVGs are an XSS vector. SVG can reference external resources via <image href="...">, leaking the viewer's IP. SVG fonts (deprecated but still parseable) historically had buffer overflows. A good optimiser strips <script> and event handlers as part of the cleanup; if you accept user SVG uploads, run them through a hardened sanitiser (DOMPurify with SVG profile) before serving.

Can I optimise SVG using the command line?

Yes. npx svgo input.svg -o output.svg uses the canonical SVGO library. Configure plugins via svgo.config.js. CI integrations: imagemin-svgo in webpack, vite-plugin-svgo, GitHub Action antfu/svg-opt. For batch optimisation: svgo -f ./icons -o ./icons-optimised. The browser tool here is faster for one-offs and works without Node installed.

Is my SVG sent to a server when I optimise here?

No. The optimisation runs entirely in your browser via JavaScript on the SVG markup you paste. Open the Network tab in DevTools while optimising; you'll see zero outbound requests. Safe for proprietary logos, unreleased icon designs, internal corporate SVGs, and anything subject to NDA.

Related Tools