How to Compress SVG Without Losing Quality

“Compress SVG” means two different things depending on who you ask. Some people mean removing redundant code from the SVG source (optimization). Others mean applying a compression algorithm like gzip or brotli to the file for transfer over HTTP. Both matter, and together they achieve the maximum size reduction.

Optimization vs. compression: the difference

Optimization changes the SVG content itself — removing metadata, rounding coordinates, collapsing paths. The resulting file is smaller in bytes and stays that way on disk.

Compression wraps the file in a compressed format (gzip, brotli) for transmission. The browser receives a compressed stream, decompresses it, and processes the SVG normally. The file on disk is unchanged; only the transfer size is reduced.

You should do both. They are not redundant — they compound each other. A smaller, cleaner source file compresses better.

Step 1: Optimize the SVG source

Run SVGO or use the svg.dog API to strip out everything a browser doesn’t need. This typically reduces file size by 40–80%. See how to optimize SVG files for the full technique breakdown.

npx svgo icon.svg -o icon.min.svg
# Before: 4821 bytes  →  After: 1204 bytes  (75% reduction)

Step 2: Enable HTTP compression

SVG files are XML text, which compresses extremely well. A 1.2 KB optimized SVG typically compresses to 500–700 bytes over the wire with gzip, and even smaller with brotli.

Check if your server already does this

Look at the response headers when fetching an SVG from your server:

curl -I -H "Accept-Encoding: br,gzip" https://yourdomain.com/icon.svg
# Look for:
Content-Encoding: br       ← brotli (best)
Content-Encoding: gzip     ← gzip (good)
# Or nothing — means no compression

Enable compression in Nginx

# nginx.conf
gzip on;
gzip_types image/svg+xml text/plain application/javascript;
gzip_min_length 256;

# For brotli (requires ngx_brotli module):
brotli on;
brotli_types image/svg+xml text/plain application/javascript;

Enable compression in Apache

# .htaccess
AddOutputFilterByType DEFLATE image/svg+xml
# Or with mod_brotli:
AddOutputFilterByType BROTLI_COMPRESS image/svg+xml

CDN-based compression (recommended)

Most CDNs — Cloudflare, Vercel, AWS CloudFront, Fastly — enable brotli and gzip compression automatically for SVG files. If you’re behind a CDN, verify it’s active for the image/svg+xml MIME type and you’re done.

SVGZ: gzip-compressed SVG files

You may encounter .svgz files — these are gzip-compressed SVG files stored on disk. Browsers can read them if the server sends the correct headers:

Content-Type: image/svg+xml
Content-Encoding: gzip

In practice, SVGZ is rarely worth the hassle. Serving regular .svg files with HTTP compression (handled by your CDN or server) achieves the same result without the deployment complexity.

Combined savings: a real example

The browser receives 820 bytes and renders the same icon as the original 8.4 KB file.

Does compression affect SVG quality?

HTTP compression is lossless. The browser receives the exact same bytes after decompression. Optimization changes the SVG source but the visual output should be identical. Always verify the optimized result renders correctly at all required sizes before deploying.

Summary

• Optimize SVG content first (SVGO, svg.dog API) — reduces file size 40–80%
• Enable gzip or brotli on your server/CDN — reduces transfer size another 60–80%
• Together, you typically go from a raw export to 5–15% of the original transfer size
• SVG quality is not affected by either technique when done correctly

For performance impact on Core Web Vitals, see SVG file size and web performance.