application/gzip Gzip Common

What it's for

application/gzip identifies data compressed with the gzip algorithm — one of the most widely implemented compression formats, used both as a standalone file compression method (most commonly paired with TAR to produce .tar.gz archives) and, separately and very commonly, as an HTTP-level compression mechanism for reducing response payload size in transit.

This second use case is worth calling out specifically because it's handled differently: HTTP response compression uses the Content-Encoding: gzip header, not the Content-Type header — a genuinely important distinction that trips up a lot of people learning about HTTP compression for the first time.

Format & syntax

As a file's Content-Type (for a standalone .gz file being served/downloaded):

Content-Type: application/gzip

As HTTP response compression (a completely different mechanism — note this uses Content-Encoding, not Content-Type):

Content-Encoding: gzip
Content-Type: application/json

In the second example, the actual content is JSON — gzip is just how it was compressed for transfer, and the client (browser or HTTP library) transparently decompresses it before handing you the real content, with Content-Type still correctly reflecting the underlying JSON data.

How it's used in practice

• HTTP response compression — nearly every production web server and CDN compresses text-based responses (HTML, CSS, JS, JSON) with gzip (or the newer, generally more efficient Brotli) before sending them, significantly reducing transfer size for compressible text content — this is almost always handled automatically by server/CDN configuration rather than application code.
• Combined with TAR for compressed archives — as covered on the TAR page, .tar.gz is the standard Unix/Linux compressed archive convention, gzip providing the compression step after TAR handles bundling.
• Log file compression — server and application logs are frequently gzip-compressed for storage efficiency, both for active rotation (compressing older log files) and for long-term archival.
• Compressed database dumps and backups — large SQL dumps and backup files are commonly gzip-compressed to reduce storage and transfer costs, often as part of the same pipeline that generates the dump itself.

Common mistakes & gotchas

• Confusing Content-Type: application/gzip with Content-Encoding: gzip — these serve genuinely different purposes: Content-Type: application/gzip says "this response body IS a gzip file" (like downloading a .gz archive), while Content-Encoding: gzip says "this response body is [some other content type], compressed with gzip for transit" — mixing these up is a common source of confusion when debugging HTTP compression behavior.
• Double-compressing already-compressed content — applying gzip compression to content that's already compressed (like JPEG images, video, or already-gzipped files) wastes CPU cycles for little to no size benefit, since compressed data doesn't compress well a second time — server compression configuration should typically exclude already-compressed file types.
• Not enabling HTTP compression at all — surprisingly still a common oversight in custom server setups or specific endpoints, leaving significant, easy performance gains on the table for text-heavy API responses or HTML pages that would benefit substantially from compression.
• Assuming gzip is still the best available HTTP compression option — Brotli generally achieves better compression ratios than gzip for web content and has broad modern browser support, making it worth considering as the primary compression method (with gzip as a fallback for older clients) rather than defaulting to gzip alone in 2026.

Comparison & FAQ

What's the difference between Content-Type: application/gzip and Content-Encoding: gzip?

Content-Type: application/gzip describes the response body itself as being a gzip file (like a downloadable archive). Content-Encoding: gzip means the underlying content (whatever its real Content-Type is) was compressed with gzip for efficient transfer, and gets transparently decompressed by the client — these are different mechanisms serving different purposes.

Should I gzip-compress images or already-compressed files?

No — compressing already-compressed data (JPEG, PNG, video, existing archives) wastes CPU with little to no size benefit, since compressed data generally doesn't compress well a second time. Server compression configuration should typically exclude these file types.

Is gzip still the best choice for HTTP compression?

Brotli generally achieves better compression ratios for web content and has broad modern browser support, making it worth using as the primary compression method today, with gzip as a fallback for any clients that don't support Brotli.

Do I need to manually enable gzip compression on my server?

Most modern web servers, frameworks, and CDNs support gzip (and often Brotli) compression, but it sometimes needs to be explicitly enabled in configuration rather than being on by default — worth checking and verifying rather than assuming it's automatically active.