How to see your svg's real transfer size after gzip and brotli compression
- Step 1Drop the SVG or paste its source — Drag an
.svgfile onto the upload zone, or paste the SVG XML into the "Or paste SVG source code" box below it. Pasted text must parse as a valid<svg>root — the tool runsisValidSvgfirst and rejects anything that isn't well-formed SVG XML. Only one file at a time; this tool is single-file (it is not the multi-file sprite builder). - Step 2Press Process SVG — There are no options to set — the estimator has an empty option schema, so the panel above the button is blank for this tool. Click Process SVG and the report is computed in-browser in milliseconds.
- Step 3Read the three size lines — The report shows
Raw size,Gzip estimate, andBrotli est., each with a byte figure and a savings percentage. Savings is computed against the raw UTF-8 byte length of your input —round((1 - compressed / raw) * 100). The metrics chips above the report repeat Gzip size, Brotli est., and Gzip savings. - Step 4Interpret the gzip number as near-exact — The gzip estimate is the actual DEFLATE output of your bytes plus 18 bytes for the gzip header/trailer. A real server adds a few more bytes (filename field, longer header) and may pick a different compression level, so treat it as accurate to within a handful of bytes, not bit-identical.
- Step 5Treat the brotli line as a rule-of-thumb — The brotli figure is
round(gzip * 0.82)— a fixed 18% reduction off the gzip estimate. It is a planning heuristic, not a measurement. Real brotli at quality 11 often beats gzip by more than 18% on large repetitive SVGs and by less on tiny icons. For a true brotli number, compress the file with a real encoder (brotli -q 11 icon.svg). - Step 6Download the report or re-run after optimising — Click Download TXT to save
{name}-compression-report.txt, or copy it to the clipboard. If the savings look low, run the file through the Pro-Minifier or Precision Tuner first, then paste the result back here to compare the before/after transfer size.
What each line in the report actually measures
Exact source of every number the estimator prints. The tool has no options — these are computed the same way on every run.
| Report line | How it is computed | Accuracy |
|---|---|---|
Raw size | new TextEncoder().encode(svg).length — the UTF-8 byte length of the file or pasted source | Exact. Matches the on-disk size for UTF-8 SVGs with no BOM |
Gzip estimate | Length of CompressionStream("deflate-raw") output + 18 bytes for the gzip header/trailer | Near-exact for default-level gzip; a real server may differ by a few bytes |
Brotli est. | Math.round(gzipEstimate * 0.82) — a flat 18% off the gzip estimate | Heuristic only. The tool does not run a brotli encoder |
| Savings % | round((1 - compressed / rawBytes) * 100) for each algorithm | Derived from the above; gzip % is reliable, brotli % inherits the heuristic |
| Fallback gzip | If CompressionStream is unavailable, gzip falls back to round(raw * 0.25) | Coarse 75%-savings guess — only triggers on browsers without CompressionStream |
Free-tier limits and accepted input
Real limits read from the SVG tier table and the tool client. The estimator runs in-process (no headless browser needed).
| Property | Value | Note |
|---|---|---|
| Accepted input | .svg file or pasted SVG source | MIME image/svg+xml; pasted text must pass isValidSvg |
| Files per run | 1 | Single-file only — drop one, or paste one snippet |
| Free tier file size | 5 MB | Per-job ceiling; larger files throw a tier-limit error |
| Pro file size | 50 MB | Pro / Pro Media raise the per-job ceiling |
| Developer file size | 2 GB | Practical ceiling is browser/runner memory |
| Output | text/plain report | Saved as {name}-compression-report.txt; the SVG is not modified |
Cookbook
Real readings from common SVG sources. The gzip figure is the tool's actual output; the brotli figure is the tool's 18% heuristic, shown so you can see exactly what the report prints.
A Figma-exported icon before any optimisation
A raw Figma export carries id attributes, a <defs> block, and verbose path data. The estimator shows the gzip win is already large because XML compresses well — but the raw number is bloated by editor cruft a minifier would remove.
Input: nav-menu.svg (Figma export) SVG Compression Estimate Report ================================ Raw size: 4.1 KB (4,182 bytes) Gzip estimate: 1.3 KB (1,331 bytes) — 68% savings Brotli est.: 1.1 KB (1,091 bytes) — 74% savings Tip: Minify with SVGO Pro-Minifier first for maximum compression benefit.
The same icon after the Pro-Minifier
After running the file through the Pro-Minifier, the raw size drops sharply. Note the gzip savings percentage falls — minified files have less redundancy left to squeeze — but the absolute transfer size is what matters, and it is much smaller.
Input: nav-menu.min.svg (after Pro-Minifier) Raw size: 1.6 KB (1,604 bytes) Gzip estimate: 742 B — 54% savings Brotli est.: 608 B — 62% savings Takeaway: gzip % dropped from 68% to 54%, but the gzipped wire size went from 1,331 B down to 742 B.
Measuring a pasted inline SVG from JSX
You can paste an inline <svg> snippet straight out of a React component to estimate what it adds to your HTML payload. The estimator parses it the same way as a file as long as it is valid SVG XML.
Pasted into the source box:
<svg viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
<path d="M4 6h16M4 12h16M4 18h16" stroke="currentColor"
stroke-width="2" fill="none"/>
</svg>
Raw size: 173 B
Gzip estimate: 158 B — 9% savings
Brotli est.: 130 B — 25% savings
Note: tiny SVGs barely compress — the gzip wrapper
overhead eats most of the gain at this size.A gradient-heavy hero illustration
Illustrations with many distinct path coordinates and gradient stops have less repetition than icon sets, so the gzip ratio is lower. The estimator surfaces that immediately so you can decide whether to ship it as SVG or rasterise.
Input: landing-hero.svg Raw size: 88.4 KB (90,520 bytes) Gzip estimate: 31.2 KB (31,948 bytes) — 65% savings Brotli est.: 25.6 KB (26,197 bytes) — 71% savings Decision: 31 KB gzipped is heavy for a hero; consider Precision Tuner at 1 dp or a WebP fallback.
An SVG with an embedded base64 raster
A <image> with a base64 PNG inside the SVG is already-compressed binary expanded 33% by base64 — it is high-entropy and barely compresses further. The estimator's low savings number is the tell to pull the raster out.
Input: badge-with-photo.svg Raw size: 62.0 KB (63,488 bytes) Gzip estimate: 47.1 KB (48,234 bytes) — 24% savings Brotli est.: 38.6 KB (39,552 bytes) — 38% savings Fix: the 24% gzip ratio is the base64 PNG. Serve the photo as a separate .webp/.png; the SVG drops to ~1 KB.
Edge cases and what actually happens
Pasted source isn't valid SVG XML
Invalid inputIf you paste markup that doesn't parse to an <svg> root, the client throws "Invalid SVG — could not parse the pasted content as valid SVG XML" before any measurement runs. This guards against pasting an HTML fragment or a truncated copy. Dropping a .svg file bypasses the paste validation but still feeds its text to the encoder.
Browser lacks CompressionStream
Fallback estimateIf CompressionStream is unavailable (very old browsers), the gzip figure falls back to round(raw * 0.25) — a flat 75%-savings guess — instead of a real measurement. Every current Chrome, Edge, Firefox, and Safari ships CompressionStream, so this fallback almost never fires, but it is why a suspiciously round gzip number can appear on an ancient browser.
Brotli line read as a real measurement
By designThe brotli figure is always exactly 82% of the gzip estimate — it is a heuristic, not an encoder output. Do not quote it as your shipped brotli size. For a precise number, run a real encoder: brotli -q 11 icon.svg and compare the .br file size.
Tiny icon shows poor savings
ExpectedAn SVG under ~200 bytes may show single-digit gzip savings or even grow slightly, because the 18-byte gzip wrapper plus DEFLATE block overhead is large relative to the payload. This is real: very small assets are often cheaper served uncompressed, and many CDNs skip compression below a size threshold (Cloudflare ~512 bytes).
File exceeds the tier size limit
413-style blockOn the free tier a file over 5 MB throws "File … exceeds the free tier per-job limit (5 MB)" and records a limit-blocked event; Pro raises it to 50 MB and Developer to 2 GB. SVGs rarely approach these sizes unless they contain embedded rasters — which is itself a signal to extract the raster.
SVG saved with a UTF-8 BOM
CountedIf your editor wrote a 3-byte UTF-8 BOM at the start of the file, those bytes are included in the raw count and fed to the encoder, so the raw number is 3 bytes higher than a BOM-less save. Strip the BOM in your build step if you want the count to match a clean export.
Server uses a different gzip level than the estimate
Minor driftThe browser's deflate-raw runs at its default level. A server configured for gzip level 9 (or level 1 for speed) will produce a slightly different size. The estimate is reliable to within a few percent for the common default levels; it is a planning figure, not a guarantee of your exact Content-Length.
Output is a report, not a smaller SVG
By designThis tool measures; it does not optimise. The downloaded file is a .txt report and outputSize equals the original size. To actually shrink the SVG, use the Pro-Minifier, Precision Tuner, Metadata Scrubber, or Unused Defs Purger, then re-measure here.
Frequently asked questions
How accurate is the gzip estimate?
Very accurate. The tool runs your bytes through the browser's native CompressionStream("deflate-raw") — the same DEFLATE algorithm gzip uses — and adds 18 bytes for the gzip header and trailer. A real web server may differ by a few bytes (it adds a filename field and may use a different compression level), so treat it as accurate to within a handful of bytes rather than bit-identical.
Does the tool actually run brotli?
No. The brotli line is computed as round(gzip * 0.82) — a flat 18% below the gzip estimate. It is a planning heuristic. The browser's CompressionStream supports gzip and deflate-raw but the tool only invokes deflate-raw, then estimates brotli from it. For a true brotli size, compress with a real encoder such as brotli -q 11.
Why does the brotli estimate look too optimistic or too pessimistic?
Because it is a fixed 18% reduction, not a measurement. Real brotli at quality 11 often beats gzip by more than 18% on large, repetitive SVGs (icon sprites, repeated path patterns) and by less than 18% on tiny icons where dictionary gains are limited. Use the line as a ballpark and verify critical assets with a real encoder.
Are my SVGs uploaded anywhere?
No. The estimator runs entirely in your browser tab using TextEncoder and CompressionStream. The file or pasted source never reaches a JAD server — the result panel even shows a "0 bytes uploaded" badge. You can measure unreleased brand assets safely.
Can I paste an inline SVG instead of uploading a file?
Yes. Use the "Or paste SVG source code" box. The pasted text must parse as valid SVG XML (it runs through isValidSvg first), so paste a complete <svg>...</svg> element, not a fragment. This is handy for measuring an inline icon copied out of a React or Vue component.
What file does the tool produce?
A plain-text report named {your-file}-compression-report.txt with the raw, gzip, and brotli lines and savings percentages, plus a tip to minify first. You can download it or copy it to the clipboard. The tool does not output a modified SVG — it is a measurement tool, not an optimiser.
Do web servers compress SVG automatically?
Most do, if the SVG is served with the image/svg+xml MIME type and text compression is enabled: Apache via mod_deflate / mod_brotli, Nginx via gzip on; / the brotli module, Cloudflare automatically. If your SVGs are served from a misconfigured static host without compression, the raw size is what users pay — this tool shows you what you're leaving on the table.
Why is the savings percentage lower after I minified the file?
Minification removes the redundant whitespace and structure that gzip was exploiting, so the percentage gzip can shave off shrinks. But the absolute transfer size is smaller — a minified-then-gzipped file beats a raw-then-gzipped one. Judge by the byte figure, not the percentage.
How big a file can I measure?
5 MB on the free tier, 50 MB on Pro, and 2 GB on Developer (read straight from the SVG tier limits). SVGs rarely approach the free cap unless they embed base64 rasters — in which case the low savings number tells you to extract the raster and serve it separately.
Does the savings percentage use the file size or the byte count?
The UTF-8 byte count of the input. Raw size is TextEncoder().encode(svg).length, and savings is round((1 - compressed / rawBytes) * 100). For a BOM-less UTF-8 SVG this matches the on-disk size; a 3-byte BOM or UTF-16 encoding will shift the count.
Can I run this without a browser, in CI?
The estimator is exposed through JAD's runner-backed API. GET /api/v1/tools/svg-compression-estimator returns the schema; the transform runs in-process on a paired @jadapps/runner at http://127.0.0.1:9789/v1/tools/svg-compression-estimator/run so files never reach JAD servers. See the batch estimation guide for the full pipeline.
Should I trust the estimate enough to set a size budget on it?
Use the gzip figure for a budget — it is within a few bytes of a default-level server. For a brotli budget, measure with a real encoder once and then track the gzip number here as a proxy, since the two move together. The estimator is ideal for catching regressions early, before a real server is in the loop.
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.