How to svg minifier: formats, file limits, and common questions
- Step 1Confirm your input is valid SVG — The tool accepts a single
.svgfile or pasted source. Pasted text is parsed first; if the root isn't<svg>or the XML is malformed you'll getInvalid SVG — could not parse the pasted content as valid SVG XMLand nothing runs. - Step 2Check your file is under the tier limit — Free is 5 MB per run, Pro 50 MB, higher tiers 2 GB. Over the limit you get a clear
exceeds the <tier> tier per-job limiterror. Oversized 'SVGs' are usually embedded rasters — see the troubleshooting table. - Step 3Run the single fixed pass — There are no options. The minifier applies its deterministic transform sequence and reports Size reduction (%), Original, and Minified bytes. Same input always gives the same output.
- Step 4Read the metrics to set expectations — High reduction (40–70%) means the file carried lots of editor metadata. Near-zero means it was already clean — that's normal and safe, not a failure.
- Step 5Pick a sibling tool for deeper optimisation — Need smaller numbers? svg-precision-tuner. Redundant polyline nodes? svg-path-simplifier. Dead defs? svg-unused-defs-purger. Metadata/a11y removal? svg-metadata-scrubber.
- Step 6Verify rendering if anything looks off — Open the minified output in a browser. The transforms are rendering-safe, so a visual change almost always points to a pre-existing issue (e.g. an
xlink:hrefthat needed the namespace) — see the edge-case table for the fix.
Format and input support
What the minifier accepts and produces. It is an SVG-in, SVG-out text tool — it does not rasterise or convert formats.
| Aspect | Support |
|---|---|
| Input file type | .svg (image/svg+xml) |
| Input via paste | Yes — raw SVG source, validated before processing |
| Files per run | One (this tool is single-file; sprite building is a separate tool) |
| Output | Minified .svg text; download as <name>-minified.svg |
| Output → PNG/JPEG | No — use a rasteriser; this tool stays vector |
| Output → base64 / data URI | No — see svg-to-base64 / svg-css-data-uri |
| Configurable options | None (one fixed pass) |
Per-tier per-run size limit
Maximum SVG processed in a single run, by subscription tier. SVG icons are almost always kilobytes, so these limits mainly catch embedded-raster or auto-traced monster files.
| Tier | Max bytes per run | Human size |
|---|---|---|
| Free | 5,000,000 | 5 MB |
| Pro | 50,000,000 | 50 MB |
| Pro + Media | 200,000,000 | 200 MB |
| Developer | 2,000,000,000 | 2 GB |
| Enterprise | null | Unlimited |
Does / does not — capability map
The single most useful table: what minify handles vs. which sibling tool owns the rest. Prevents wrong expectations.
| Want to… | Minifier? | Right tool |
|---|---|---|
| Remove comments + whitespace | Yes | This tool |
| Strip editor namespaces | Yes | This tool |
| Fold empty elements / drop empty attrs | Yes | This tool |
| Round coordinate precision | No | svg-precision-tuner |
| Reduce redundant path points | No | svg-path-simplifier (polylines only) |
| Remove unused defs | No | svg-unused-defs-purger |
| Remove metadata / title / desc | No | svg-metadata-scrubber |
| See gzip/brotli wire size | No | svg-compression-estimator |
| Combine many icons into one file | No | svg-sprite-builder |
Cookbook
Quick reference snippets: what the pass changes, what it doesn't, and how to read the result. Use these to verify the tool matches your expectations before relying on it.
The full transform sequence on one file
A compact example that exercises every transform: comment, prolog, editor NS, whitespace, empty element, empty attribute.
Before:
<?xml version="1.0" encoding="UTF-8"?>
<!-- icon -->
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
id="" viewBox="0 0 24 24">
<g></g>
<path d="M3 12h18"/>
</svg>
After:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><g/><path d="M3 12h18"/></svg>Reading the result metrics
The output panel reports three numbers. Here's how to interpret them.
Size reduction: 68% Original: 4.10 KB Minified: 1.31 KB 68% → the file carried a lot of editor metadata (good candidate). A result near 0% just means the file was already clean — safe, not an error. The reduction is on RAW bytes, before gzip.
Valid vs invalid paste
Pasted source is validated as well-formed SVG with an <svg> root before processing.
Valid (processed): <svg xmlns="http://www.w3.org/2000/svg"><rect width="4" height="4"/></svg> Invalid (rejected, nothing changed): <div>not svg</div> → "Invalid SVG — could not parse the pasted content as valid SVG XML" Also invalid: truncated/malformed XML, or a stray copied character before the <svg> tag.
When NOT to expect smaller numbers
Minify removes metadata, not geometry. Long coordinate strings stay until you run the precision tuner.
Minify output (numbers untouched): <path d="M12.347826 4.913043 L19.082608 11.500000"/> This is correct behaviour. For smaller path data: svg-precision-tuner @ 2 decimals → <path d="M12.35 4.91 L19.08 11.5"/>
Diagnosing an oversized 'icon'
If minify barely helps a large file, it's likely a raster in disguise.
minify result on a 240 KB file: 1% reduction. Grep the source: <image href="data:image/png;base64,iVBORw0KGgoAAAANS..."/> → embedded PNG. Minify can't compress raster bytes. Re-export as true vector, or serve PNG/WebP directly.
Edge cases and what actually happens
Pasted content isn't valid SVG
InvalidThe tool parses pasted source and requires an <svg> root. Anything else (HTML, partial XML, a stray leading character) is rejected with Invalid SVG — could not parse the pasted content as valid SVG XML, and no transform runs. Re-copy the full, well-formed SVG.
File over the tier byte limit
413 too largePer-run ceilings: 5 MB (free), 50 MB (Pro), 200 MB (Pro+Media), 2 GB (Developer), unlimited (Enterprise). Over the limit you get exceeds the <tier> tier per-job limit. Genuine vector SVGs rarely approach these; an oversized file usually contains an embedded raster.
Reduction is near 0%
ExpectedThe file was already minified or hand-written with little metadata. This isn't a failure — there's simply nothing to remove. The pass is idempotent, so re-running an optimised file is harmless and produces identical bytes.
xlink:href stopped working after minify
Check referencesThe minifier drops xmlns:xlink only when no xlink: attribute remains. If a reference broke, the source likely had an xlink:href the parser didn't see (e.g. inside a CDATA/script block). Switch to plain href (modern SVG) or keep the declaration; re-running won't drop it while a real xlink: use exists.
Coordinates unchanged
By designMinify never rounds numbers — long coordinate strings are preserved exactly. This is intentional to avoid altering geometry. Use svg-precision-tuner (0–4 decimals) when you want smaller numeric values.
title/desc still present
PreservedAccessibility elements are kept on purpose so screen readers still work. If you specifically need them removed, that's svg-metadata-scrubber — a separate, intentional action.
Expected SVGO plugin options
Not applicableThere are no plugin toggles — this isn't SVGO. The tool runs one fixed safe pass. For SVGO-style number/path crunching, chain svg-precision-tuner and svg-path-simplifier, or use the SVGO CLI directly.
Output won't render as a PNG
Wrong toolMinify produces SVG text, not a raster. It doesn't convert formats. To get base64/data-URI strings use svg-to-base64 or svg-css-data-uri; to rasterise, use a dedicated converter.
Multiple files at once
UnsupportedThis tool processes one SVG per run. Sprite/batch composition is a different tool — svg-sprite-builder combines multiple SVGs into one. For bulk minification, automate via the runner (see the GitHub Actions guide).
Frequently asked questions
What exactly does the minifier remove?
A fixed sequence: XML comments, whitespace between tags, the <?xml?> declaration, editor-only namespaces (xmlns:dc, xmlns:cc, xmlns:rdf, xmlns:sodipodi, xmlns:inkscape, redundant xmlns:svg, and xmlns:xlink when unused), empty elements (folded to self-closing), and empty attr="" strings. That's the whole list — nothing else changes.
What does it deliberately NOT do?
It does not round coordinates, simplify or merge path data, remove the viewBox, strip <title>/<desc>, prune unused defs, or minify embedded CSS. Each of those is owned by a dedicated tool so the change is explicit and you never lose geometry or accessibility by accident.
Is this SVGO?
No. It's a curated set of guaranteed-safe text transforms, not the SVGO plugin engine — despite the 'Pro-Minifier' name. It intentionally omits SVGO's geometry-altering plugins. For SVGO-style rounding/path crunching, chain svg-precision-tuner and svg-path-simplifier, or run the SVGO CLI.
What input formats are accepted?
A single .svg file (drag/drop or browse) or pasted SVG source. Pasted text is validated as a well-formed <svg> document before any processing. The tool is SVG-in, SVG-out — it doesn't accept or produce PNG/JPEG.
What's the maximum file size per tier?
5 MB on Free, 50 MB on Pro, 200 MB on Pro+Media, 2 GB on Developer, and unlimited on Enterprise — per run. Real vector icons are kilobytes, so you'll rarely hit these; an oversized 'SVG' is usually an embedded raster the minifier can't compress.
Can I minify several files at once?
Not in this single-file tool — it processes one SVG per run. To combine multiple SVGs into one file, use svg-sprite-builder. For bulk/automated minification, pair the @jadapps/runner and script it (see the GitHub Actions guide).
Are there any settings or options?
No. The minifier runs one deterministic pass with no checkboxes or sliders. This makes output reproducible (ideal for CI diffs) and removes any chance of enabling a risky transform. Options live in the dedicated sibling tools where a real choice exists.
Why did my file barely get smaller?
Either it was already optimised (near-zero reduction is normal and safe), or it's mostly raster data — an <image> with a base64 PNG/JPEG inside an SVG wrapper, which the minifier can't compress. Check the source; if you find an embedded raster, re-export as true vector.
Will minifying break my SVG's rendering?
It shouldn't — every transform is rendering-safe. The one thing to watch is xlink: the tool drops xmlns:xlink only when no xlink: attribute remains, so references stay valid. If something looks off, open the output in a browser; a visual change almost always traces to a pre-existing source issue.
What browsers does it work in?
Any modern browser — it's standard in-browser JavaScript using the platform's XML parsing and text-encoding APIs. There's no plugin, extension, or server dependency. It also runs server-side via the @jadapps/runner for automation, since the minify pass is pure text.
Is my file uploaded anywhere?
No. Processing is entirely in-browser; the SVG bytes never leave your machine. The only thing recorded is an anonymous 'tool ran' counter for signed-in dashboard stats — never the file content. The same privacy holds on the runner path, where the transform runs locally.
What does the downloaded file get named?
Your original filename stem plus -minified — e.g. icon.svg downloads as icon-minified.svg. Pasted source (with no original name) downloads under a default stem. The suffix keeps your source file untouched.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.