Encoding
Gzip/Deflate ↔ Base64
Compress text with Gzip or Deflate, then Base64-encode the result — and back. Powered by the Compression Streams API, right in your browser.
Base64 by itself doesn't compress anything — quite the opposite, it grows the size by about 33%. To send large text compactly through a text-only channel, it's first compressed with Gzip or Deflate, and only then is the result Base64-encoded.
How to use it
- Compress: paste text and the tool compresses it with Gzip or Deflate (the browser's Compression Streams API) and encodes the result as Base64.
- Decompress: paste a Base64 string of compressed content to get the original text back.
- Pick Gzip or Deflate depending on which format the receiving system expects.
Common uses
- Compactly embedding a large text value (an SVG, a config) in a URL parameter or cookie with a size limit.
- Preparing a compressed payload for an API that accepts Base64-encoded Gzip data.
- Decompressing data received in this format from another system so it can be read manually.
Things to keep in mind
Compression only pays off on sufficiently large, compressible text — on short strings the Gzip header overhead plus the Base64 expansion can actually make the result bigger.
Deflate skips Gzip's headers, so its output is more compact, but the format is less self-describing: the receiving side needs to know in advance that it's Deflate specifically.
Article about this tool: Gzip + Base64: compressing data for text-based transfer
Frequently asked questions
What's the difference between Gzip and Deflate here?
Gzip wraps the compressed data in a header and a trailing CRC checksum, while Deflate is the raw compression stream without that wrapper. Data compressed with one format can't be decoded by picking the other — make sure the selected format matches how the data was produced.
Why do I need to Base64-encode the compressed data?
Gzip/Deflate output is raw binary, which doesn't survive well in text contexts like URLs, JSON, or config files. Base64-encoding it turns that binary data into safe, copyable ASCII text.
Why does the tool say my browser doesn't support this?
This tool relies on the browser-native Compression Streams API (CompressionStream/DecompressionStream), which isn't available in every browser or older version — no data is sent to a server, so if it's unsupported the tool simply can't run.
Why does decompression sometimes fail with an "invalid header" error?
The most common cause is a mismatched format: data compressed as "raw" Deflate without a header, but decompressed as Gzip (which expects its own header and a CRC-32), or vice versa. Try switching the format in the tool's settings.
Does compression always reduce the final size?
No. On very short strings, the overhead of Gzip headers plus the growth from Base64 can outweigh the savings from compression — this approach only makes sense for sufficiently large, compressible text data.