Lossless Compression: Definition, Algorithms, Web Use

What is lossless compression?

Lossless compression reduces file size without discarding any information: decompressing gives back exactly the original bytes. It works by encoding repeated patterns more compactly, so text, code, JSON and HTML shrink a lot, while data that is already compressed barely changes.

The alternative is lossy compression, which permanently drops detail the eye or ear is unlikely to miss (JPEG, MP3, most video). Use lossless wherever every bit matters: source code, executables, databases, archives and the HTML, CSS, JavaScript and JSON your server sends.

How lossless compression works

Lossless algorithms find redundancy and remove it. Two techniques do most of the work:

• Dictionary coding (the LZ77 family): replace a repeated string with a short reference to an earlier copy. gzip, Zstandard and LZ4 are built on it.
• Entropy coding (Huffman, arithmetic coding): give frequent symbols shorter codes than rare ones. Most compressors use it as a final pass.

Brotli combines these ideas with context modelling and a built-in dictionary. MDN notes that text can have as much as 60% redundancy, which is why it compresses so well.

Common lossless algorithms

Lossless versus lossy

Lossless gives back the exact original. Lossy gives back an approximation and usually reaches smaller sizes. Some formats, such as WebP, support both modes.

Lossless compression on the web

HTTP compression is lossless. The browser lists what it supports in Accept-Encoding, the server picks one, compresses the body and labels it in Content-Encoding. The Vary: Accept-Encoding header lets caches and CDNs store each variant separately.

GET / HTTP/1.1
Accept-Encoding: br, gzip

HTTP/1.1 200 OK
Content-Encoding: br
Vary: Accept-Encoding
Content-Type: text/html

The encodings you will meet in practice (see MDN's compression guide):

Serve Brotli where the client supports it and fall back to gzip. MDN says compression can cut some documents by up to 70%, which lowers transfer time and can improve load metrics such as LCP (see Core Web Vitals). For a server-side setup walkthrough, see enabling gzip on NGINX.

Which compressor to use

• HTML, CSS, JavaScript, JSON over HTTP: Brotli, with gzip as the fallback. For static files, compress once at build time at a high level. For dynamic responses, use a faster, lower level so CPU time does not add to latency.
• Real-time streams and in-memory data: LZ4 or Snappy, which give up ratio for speed.
• Long-term archives: xz or Zstandard at a high level, where ratio matters more than speed.
• Logs and many similar payloads: Zstandard, optionally with a shared dictionary.

Common mistakes

• Compressing files that are already compressed. JPEG, MP4, ZIP and similar formats will not shrink, and the extra pass wastes CPU and can make the file larger.
• Compressing images with a text algorithm. Serve images in an image format instead. See image size.
• Forgetting Vary: Accept-Encoding. Without it a cache can hand a compressed response to a client that cannot read it.
• Using a maximum level on every request. The last few percent of size cost a lot of CPU. Reserve it for files you compress once.
• Assuming compression is on. A proxy, CDN or origin setting can switch it off without any visible error. Check the response headers.

Checking compression with LoadFocus

A misconfigured server can ship uncompressed JSON for months without anyone noticing. LoadFocus API monitoring can assert on response headers as well as status code, body and response time, so you can fail a check if Content-Encoding is missing, and it breaks response time into wait, DNS, TCP connect, first byte (TTFB) and download. Free checks run every 5 minutes. A load test from 25 regions reports response time percentiles, latency and throughput under load, which shows whether compression CPU cost is hurting you at peak.

FAQ: Lossless Compression

What is the best lossless compressor?

It depends on what you trade. xz gives a high ratio but is slow, Zstandard balances speed and ratio, LZ4 is the fastest, and gzip is the most compatible. For web responses, Brotli with a gzip fallback.

Why does my file not get smaller?

It probably has no redundancy left. JPEG, MP4, encrypted data and already-compressed archives are close to random to a compressor.

Should I compress JSON?

Yes. JSON repeats key names heavily, so it usually compresses well. Enable gzip or Brotli on your API responses and confirm with the response headers.

Is PNG lossless?

Yes. PNG and GIF are lossless, JPEG is lossy, and WebP can be either. Use PNG for screenshots and logos and JPEG or WebP for photos.

Is Brotli better than gzip?

For text over HTTP, usually yes: its README describes it as similar in speed to deflate but denser. Support is wide, so serve Brotli and keep gzip as the fallback.

Should I compress before encrypting?

If you encrypt files yourself, yes, because encrypted output looks random and will not compress. HTTP compression is applied on the response before TLS.