SVG Optimizer
Remove XML metadata, strip comments, and collapse whitespace so SVG artwork ships faster.
Optimizing vectors...
Drop SVG icons, illustrations, or zipped libraries
Everything stays client-side until you approve cleanup, and previews highlight path changes.
SVG queue
- Add SVG files to preview their size and status before minifying.
Optimized SVGs will appear here with size savings and download buttons.
The SVG optimizer strips bloat from SVG files at the text level. It removes XML comments, the optional XML declaration, and the entire metadata block, then collapses whitespace between tags. Visible markup, attributes, paths, and rendering behavior are unchanged. Up to 50 files per batch, 40 MB per file. Typical hand-authored or design-tool exports compress by 20 to 60 percent with no visual difference.
What the Optimizer Removes
Three independent options, each safe to apply on any valid SVG:
- Remove XML comments: deletes all
<!-- ... -->blocks. Comments are common in design-tool exports (Illustrator, Sketch, Figma all add comments like "Generator: Sketch 96") but are completely ignored by the renderer. - Remove metadata: deletes the entire
<metadata>...</metadata>block (which often contains RDF, license info, or design-tool tracking data) and the optional<?xml ... ?>declaration at the top of the file. Both are invisible to the rendered output and routinely add 100 to 500 bytes per file. - Collapse whitespace: removes whitespace between tags (the indentation that makes SVG human-readable) and collapses runs of multiple spaces to single spaces. Most design tools export SVG indented for editor display; the renderer does not care.
What the Optimizer Does Not Touch
The optimizer is intentionally conservative. It only modifies the text wrapping around the actual SVG content; it does not touch the SVG itself. Specifically:
- Path data is unchanged. Path coordinates, decimal precision, and curve commands are kept exactly as the source wrote them. A 14-decimal-place coordinate stays 14 decimal places.
- Attributes are kept verbatim. No deduplication, no simplification, no shortening of color values, no consolidation of transforms.
- No element pruning. Invisible elements, unused defs, and zero-size shapes are preserved.
- No viewBox or dimension recomputation.
The benefit is safety: the output renders identically to the source on every browser. The tradeoff is that you cannot squeeze the absolute last byte out of a complex SVG the way a full optimizer (SVGO with all plugins enabled) can. For most hand-authored or design-tool-exported SVGs the savings from comment, metadata, and whitespace removal alone are 20 to 60 percent, which covers the typical case. If you need deeper optimization (path simplification, decimal rounding, color shortening), use a dedicated tool like SVGO afterward.
When SVG Optimization Matters
- Icon sets shipped on the web: a typical UI uses dozens of SVG icons. Optimizing each before deploy compounds across every page load.
- Inline SVGs in HTML: when SVG is embedded directly in the page source (instead of loaded as an external file), every byte of bloat adds to the HTML payload that blocks the first paint.
- SVG illustrations on landing pages: hero illustrations exported from Illustrator or Figma routinely carry 30 to 50 percent invisible overhead.
- Logos and favicons: the brand SVG is loaded on every page of a site. Trimming it once delivers permanent savings.
- SVG assets in mobile apps: app bundle size matters; cleaner SVGs ship in smaller bundles.
Workflow Notes
Optimize as the last step before deploy or commit. The output is still a fully editable SVG (the optimizer only removes invisible content), but it is no longer human-friendly because of the collapsed whitespace. Keep your source files in the original indented form so you can continue editing in your design tool or hand-tweak the markup later. For files where the optimizer's savings are not enough (heavy illustrations with many path coordinates), consider running the result through a path-aware optimizer like SVGO before publishing.
SVG is a vector format and renders crisply at any size, but if you actually need a raster output for a context that does not support SVG (older email clients, certain print pipelines), the image converter renders the SVG to PNG, JPG, or WebP at any pixel dimensions. To bundle a set of SVGs into a single shareable document, the image-to-PDF converter packs them into a multi-page PDF.
Batch Optimization and Privacy
Each optimization runs in memory on the server. Files stream to the optimizer endpoint, get processed as text (the SVG itself is text, not binary like JPG or PNG), and return inside the JSON response. Nothing is written to disk, indexed, logged, or cached. The buffer is released as soon as the response is sent. Up to 50 files per batch, 40 MB per file. ZIP archives are unpacked server-side and each entry counts against the same 50-file limit. The same three options apply to every file in a batch. Outputs are returned individually or repackaged into a single download ZIP for batches above one file.
FAQ
For most hand-authored or design-tool-exported SVGs, expect 20 to 60 percent size reduction. The exact savings depend on how the source was generated. Illustrator and Sketch exports with embedded metadata, comments, and indented markup save the most (often above 40 percent). Already-clean SVGs (hand-written or pre-cleaned by another tool) save less. The savings come from comments, the metadata block, the XML declaration, and whitespace between tags. The actual visible markup is unchanged.
Yes. The optimizer only removes XML comments, the metadata block, the XML declaration, and whitespace between tags. None of those affect rendering. Path coordinates, attributes, fills, strokes, transforms, viewBox, gradients, filters, and animations all pass through unchanged. The output produces pixel-identical results in every browser.
No. Path data is preserved verbatim. A coordinate written as 47.3892756432198 stays at 13 decimal places in the output. The optimizer is intentionally conservative; it does not touch the SVG geometry at all. This keeps the output guaranteed-safe and visually identical to the source. For deeper optimization that includes decimal rounding and path simplification, run the optimized file through a dedicated tool like SVGO afterward.
For SVG embedded inline in HTML or referenced via img/object tags in modern browsers, yes. The XML declaration (<?xml version="1.0" encoding="UTF-8"?>) is optional and routinely omitted from inline SVG. For standalone SVG files served with the application/svg+xml MIME type, the declaration is technically recommended by the XML spec but no modern browser requires it. If you have a specific consumer that complains about its absence (a print workflow, an older XML parser), turn off the metadata-removal option to keep the declaration in place.
Yes, the optimized file is still a fully valid SVG that opens in any vector editor (Illustrator, Inkscape, Figma, Sketch, etc.). However, the collapsed whitespace makes the source noticeably less readable if you open it in a text editor for manual tweaks. The recommended workflow is to keep the original indented version as your source of truth, and only feed the optimized version into production. When you need to make changes, edit the source and re-run the optimizer.
No. SMIL animations (animate, animateTransform, animateMotion), CSS classes and inline styles, JavaScript hooks via IDs, and click/hover interaction targets all live in the visible markup, which the optimizer does not touch. Only comments, the metadata block, the XML declaration, and inter-tag whitespace are removed. Animated logos, interactive SVG diagrams, and embedded CSS animations continue working exactly as before.
SVGO is a deep optimizer that understands SVG semantically; it can simplify paths, round decimal coordinates, deduplicate attributes, merge sibling elements, drop unused defs, shorten color values, and more. This tool is a lightweight text-level cleaner that only removes comments, metadata, and whitespace. The difference is conservatism: this tool will never break an SVG because it does not touch the geometry or attributes; SVGO can occasionally introduce subtle rendering differences when one of its aggressive plugins runs. For most use cases, the lightweight cleanup here is enough. For minimal-byte optimization, run SVGO afterward.
Yes. Up to 50 SVG files per batch, 40 MB per file. The same three options (remove comments, remove metadata, collapse whitespace) apply to every file in the batch, which is what you want when optimizing a whole icon set or a folder of design-tool exports. ZIP archives are unpacked server-side and each entry counts against the same 50-file limit. Outputs are returned individually or repackaged into a single download ZIP.
No. Files are processed entirely as text in memory on the server. Nothing is written to disk, indexed, logged, or cached. The buffer is released as soon as the response is sent. The tool requires no registration and does not track which SVG files you have optimized.
Free with no registration. No rate limits, no watermarks added to outputs, no premium tier with extra features held back. The same applies to all imgdeal tools, including format conversion, compression, resizing, and cropping.