How to maximising svg compression ratios: benchmarks and tips
- Step 1Measure the current ratio — Drop the SVG on the Compression Estimator and read the gzip savings percentage. That percentage is the compression ratio (1 - gzip/raw). Under ~50% is a flag worth investigating.
- Step 2Classify the SVG by content type — Is it a clean icon, a path-heavy illustration, an icon sprite, or does it embed a base64 raster? Match it to the benchmark table below to see whether its ratio is normal or unusually low.
- Step 3Hunt for low-compressibility content — The usual culprit for a poor ratio is an embedded base64
<image>— already-compressed binary, expanded 33% by base64, with almost no redundancy to squeeze. Identify and remove it. - Step 4Extract embedded rasters — Move any embedded photo to a separate
.webp/.pngand reference it instead of inlining. The SVG's ratio jumps because what's left is markup, which compresses well. Re-estimate to confirm. - Step 5Regularise and minify — Consistent attribute order, repeated element names, and tuned precision give the compressor more matches to find. Run the Precision Tuner and Pro-Minifier, then re-estimate.
- Step 6Re-measure and decide — Compare before/after gzip bytes. If a large illustration still compresses poorly and looks photographic, consider shipping a raster instead. Let the estimator's number drive the decision.
Expected gzip/brotli ratios by SVG type
Realistic ranges, not guarantees. Gzip savings = (1 - gzip/raw); brotli is typically a few points better. Measure your own files.
| SVG type | Typical gzip savings | Why |
|---|---|---|
| Minified single icon | 55-75% | Already dense; less redundancy left, but markup still compresses |
| Raw editor-export icon | 65-85% | Whitespace + metadata + verbose attrs give lots to squeeze |
| Icon sprite (many similar paths) | 80-92% | High repetition across symbols; brotli's window helps even more |
| Gradient / path-heavy illustration | 55-75% | Diverse coordinates and stops limit matchable redundancy |
| Tiny icon (< 200 bytes) | 0-25% | Gzip wrapper + block overhead is large relative to payload |
| SVG with embedded base64 raster | 10-35% | High-entropy already-compressed binary; the raster doesn't shrink |
What drives SVG compressibility
The structural factors behind a high or low ratio, and the lever that moves each.
| Factor | Effect on ratio | Lever |
|---|---|---|
| Repeated element/attribute names | Higher — more dictionary matches | Keep consistent markup; minify |
| Whitespace and indentation | Higher raw, then squeezed out | Minify (raw drops, ratio drops too) |
| Coordinate precision | Long decimals = less regular tokens | Precision Tuner @ 1-2 dp |
| Embedded base64 data | Much lower — high entropy | Extract raster to a separate file |
| Unique gradient stops / colours | Lower — fewer repeats | Reduce stops where visually safe |
| File size | Larger files reach higher ratios | Bundle tiny icons into a sprite |
Cookbook
Diagnostic readings that explain a ratio. Gzip is the estimator's real output; brotli is its 18% heuristic.
Excellent ratio — repetitive sprite
A sprite of similar outline icons shares path shapes and attribute patterns, so the compressor finds many matches. This is near the top of what SVG can achieve.
outline-icons.svg (48 symbols) Raw: 52.0 KB Gzip: 4.7 KB — 91% savings Brotli: 3.8 KB — 93% savings Why: heavy repetition across <symbol> elements.
Poor ratio — embedded base64 photo
The low savings number points straight at an embedded raster. The base64 blob is already-compressed, high-entropy data the compressor can't reduce.
team-photo-badge.svg Raw: 71.0 KB Gzip: 55.4 KB — 22% savings Brotli: 45.4 KB — 36% savings Diagnosis: a base64 <image> is ~62 KB of the 71 KB.
Same badge after extracting the raster
Pull the photo out to a separate file and reference it. What remains is markup, which compresses well — and the total bytes shipped drop dramatically.
team-photo-badge.svg (raster extracted to .webp) Raw: 1.4 KB Gzip: 612 B — 57% savings Brotli: 502 B — 65% savings + team-photo.webp served separately (cacheable). Net payload far smaller than the 71 KB inline version.
Middling ratio — gradient illustration
Lots of unique coordinates and gradient stops cap the ratio. This is normal for illustrations — there's only so much repetition to exploit.
abstract-bg.svg Raw: 44.0 KB Gzip: 16.3 KB — 63% savings Brotli: 13.4 KB — 70% savings Normal for path-heavy art; not a defect.
Diminishing returns — minified vs. raw
Minifying first lowers the gzip percentage (less redundancy left) but the gzipped byte size is smaller. The byte figure, not the percentage, is the win.
card.svg raw: Raw 7.9 KB Gzip 2.4 KB (70%) card.min.svg: Raw 2.8 KB Gzip 1.1 KB (61%) Percentage fell 70% -> 61%, gzipped bytes fell 2.4KB -> 1.1KB. Ship the minified one.
Edge cases and what actually happens
Low ratio caused by an embedded base64 raster
Won't improveIf the gzip savings sit in the 10-35% range, an embedded base64 <image> is almost certainly the cause. That data is already compressed and expanded 33% by base64 — no SVG tool will squeeze it. Extract the raster to a separate .webp/.png and reference it; the SVG's ratio recovers immediately.
Tiny icon barely compresses
ExpectedAn SVG under ~200 bytes can show single-digit savings or even grow, because the gzip wrapper and DEFLATE block overhead are large relative to the payload. This is not a defect — bundle many tiny icons into a sprite so they compress together and the overhead amortises.
Minified file shows a lower percentage than the raw one
ExpectedCounterintuitive but correct: minification removes the redundancy gzip exploited, so the percentage falls — while the gzipped byte size is smaller. Always compare absolute gzip bytes, not the savings percentage, when deciding which file to ship.
Gradient-heavy illustration won't break 75%
By designIllustrations with thousands of unique path coordinates and many gradient stops have limited repetition for the compressor to find, so 55-75% is normal. There's no bug — if the byte size is still too large, consider a raster fallback (WebP/AVIF) for photographic content.
Two visually identical SVGs compress differently
Structure-dependentCompression keys on byte-level repetition, so two icons that look the same but have different attribute ordering, number formatting, or path encoding can have different ratios. Normalise via the Pro-Minifier (consistent output) before comparing ratios.
Precision tuning improved the ratio more than expected
BonusRounding coordinates to 1-2 dp doesn't just cut raw bytes — shorter, more uniform numbers create more matchable tokens, so the gzip ratio can improve too. Re-estimate after tuning to capture both effects.
Brotli ratio mistaken for a real measurement
HeuristicEvery brotli figure in the report is exactly 18% under the gzip estimate by formula, so its savings percentage is derived, not measured. The benchmark ranges that include brotli are based on the heuristic; verify a critical asset with a real brotli -q 11 run.
Ratio looks fine but the wire size is still large
Wrong targetA 70% ratio on a 90 KB illustration still ships ~27 KB. A good ratio doesn't mean a good budget. Judge the absolute gzipped bytes against your per-asset budget, not the percentage alone.
Frequently asked questions
What's a typical compression ratio for a well-optimised SVG icon?
A minified icon usually gzips to 25-45% of its raw size — a 55-75% saving. A sprite of many similar icons does better (80-92%) thanks to repetition. Brotli typically adds a few more points. Measure your own with the estimator's gzip line; ranges are guidance, not guarantees.
Why does my SVG with an embedded image compress so poorly?
An embedded base64 raster is already-compressed binary, expanded 33% by base64 encoding, with very little redundancy. The compressor can't reduce high-entropy data, so the overall ratio collapses to 10-35%. Extract the raster to a separate .webp/.png and reference it — the SVG's ratio recovers immediately.
Does minification actually improve the compression ratio?
It lowers the percentage but reduces the absolute size. Minification strips the whitespace and redundancy gzip was using, so there's less left to compress (lower percentage), but the resulting gzipped file is smaller. Ship the minified file and judge by bytes, not by ratio.
What's the maximum realistic SVG compression ratio?
Highly repetitive content — icon sprites with many similar paths — can reach 90%+ gzip savings, and brotli a couple of points more. Diverse illustrations top out around 60-75%. Tiny icons compress poorly because of wrapper overhead. The estimator shows your specific file's ceiling.
Is the brotli savings number in the report measured?
No. The estimator computes brotli as a flat 18% below the gzip estimate, so its savings percentage is derived, not measured. Use the gzip percentage as the reliable ratio and treat brotli as a ballpark; verify with a real encoder if it matters.
How do I improve a low compression ratio?
Three levers: extract any embedded base64 raster (biggest single fix for poor ratios), regularise the markup and tune coordinate precision so the compressor finds more matches, and minify. Re-estimate after each step. If the file is photographic, a raster may simply be the right format.
Why do two SVGs that look identical compress differently?
Compression works on byte-level repetition, so differences in attribute order, number formatting, or path encoding change the ratio even when the rendered image is identical. Normalise both with the Pro-Minifier before comparing.
Should I always chase the highest ratio?
No — chase the lowest absolute gzipped bytes against your budget. A 70% ratio on a large illustration can still be heavier than a 55% ratio on a small one. The percentage is diagnostic; the byte figure is what users download and what you budget on.
Does coordinate precision affect the ratio or just the raw size?
Both. Fewer decimal places shorten every number (smaller raw size) and produce more uniform tokens (more matchable repetition, better ratio). The Precision Tuner at 1-2 dp usually improves both at once — re-estimate to see the combined effect.
When is it not worth compressing an SVG?
Tiny icons (sub-200 bytes) gain little because the gzip wrapper overhead is significant, and many CDNs skip compression below ~512 bytes anyway. For lots of tiny icons, bundle them into a sprite so they compress as one larger, more redundant payload.
How accurate is the gzip ratio the estimator reports?
Very. It's derived from the real deflate-raw output plus an 18-byte wrapper, so it's within a few bytes of a default-level server's gzip. It's a dependable basis for setting and tracking compression-ratio expectations across your asset set.
Can I benchmark a whole icon set at once?
Yes — run each file through the runner-backed API and record the gzip ratio per file. See the batch estimation guide. Plot the ratios to spot outliers (usually files with embedded rasters) for targeted fixes.
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.