Gzip and Deflate are compression algorithms that shrink data, but the result is binary, not text. If compressed data needs to travel over a text-only channel (a URL, a cookie, a JSON field), it's additionally Base64-encoded — hence the pairing "Gzip/Deflate ↔ Base64." Whiteboard and diagramming tools like Excalidraw use exactly this trick to pack an entire canvas's JSON state into a shareable URL.
Why compression works so well on ordinary English text
Compression algorithms like Deflate exploit the fact that letters and words don't appear with equal frequency — 'e', 't', and 'a' show up constantly in English prose, and common words like "the" and "and" repeat throughout any document. That predictability is exactly what lets Gzip replace repeated patterns with much shorter references, which is why plain-English JSON or log files routinely compress to a third of their original size or less.
The typical order of operations
- The original text is compressed with Gzip or Deflate — the size shrinks.
- The compressed binary result is Base64-encoded — the size grows back a bit, but the data is now text.
- The resulting string is safely passed through a text channel.
Decoding runs in reverse: Base64 → binary data first, then Gzip/Deflate decompression → the original text.
Common use cases
- Packing an app's entire state into a URL so a link can be shared and reopened exactly as left.
- Storing compressed data in a cookie or a text database field.
- Debugging: unpacking and reading content encoded this way by a third-party system or API.
Gzip vs. "raw" Deflate
Gzip is essentially a wrapper format around the Deflate algorithm: it adds its own header and a checksum (CRC-32) on top of the compressed data. "Raw" Deflate lacks these extra bytes, so the result is slightly more compact, but it can't be unpacked with a gzip utility without explicitly stating it's the raw format. Confusing the two is a common cause of an "invalid header" error when trying to decompress data.