About Gzip Compressor & Decompressor
Gzip Compressor & Decompressor compresses text or a file to a gzip stream and expands gzip data back to text or bytes, with an option to represent the compressed result as Base64 so it can travel through a text-only field. The result pane always offers a download, which is the only way to move real binary output out of a browser intact.
Gzip is a container around a DEFLATE stream: a ten-byte header starting with the magic bytes 1F 8B 08, the compressed data, then a CRC-32 and the original length. That framing is why gzip, zlib, and raw DEFLATE are not interchangeable even though all three carry the same compressed payload, and why a stream that decompresses in one library fails in another. Compression is also not free at small sizes; below a few hundred bytes the header and trailer cost more than the compression saves.
How to use this developer tool
- Choose Compress or Decompress. The mode decides how the input pane is interpreted.
- For compression, type or paste text, or pick a file; for decompression, paste Base64-encoded gzip data or pick a .gz file.
- Leave the Base64 output box ticked when you want a copyable string, and untick it when you only intend to download the bytes.
- Run the operation and read the result pane: text output appears directly, binary output is reported as a size because it cannot be shown as text.
- Copy the Base64 string, or download output.gz for compressed data and output.bin for decompressed binary.
Worked example: how well a log sample actually compresses
Four structured log lines, 364 bytes including the trailing newline. Repetitive keys are exactly what DEFLATE is good at.
{"ts":"2026-02-02T02:40:00Z","level":"info","path":"/api/v1/orders","status":200,"ms":37}
{"ts":"2026-02-02T02:40:01Z","level":"info","path":"/api/v1/orders","status":200,"ms":41}
{"ts":"2026-02-02T02:40:02Z","level":"warn","path":"/api/v1/orders/9f2","status":404,"ms":12}
{"ts":"2026-02-02T02:40:03Z","level":"info","path":"/api/v1/orders","status":201,"ms":88}
H4sIAAAAAAAAA6XOsQ6CMBAG4J3H+OeSXo9G8Z7Dya2JJZIgkF7BgfDuDiwsMOgLfPkWZIWAiS8lcUl8JxZPQvSAQRfn2EHQ9s0AgzHkFwQ2jK2dnR3SMyaFgeaQJ4UwkcFbIdV1LZYj2f0je3ci817+hNQfyfbW8E735Dfd8Yle/fR2m1zXa/EFnwXx42wBAAA=The gzip stream is 146 bytes, 40 percent of the input. The Base64 form is 196 characters, so the version you can paste into a JSON field is still 54 percent of the original text. If the payload will be transported as bytes, quote the 146; if it will be pasted as text, quote the 196.
Compressed formats and their headers
The first bytes identify the format. This is the fastest way to explain why a payload one system produced cannot be read by another.
| Format | First bytes | Framing | Accepted by this tool |
|---|---|---|---|
| gzip | 1F 8B 08 | 10-byte header, CRC-32 and length trailer | Yes, this is the default |
| zlib | 78 01 / 78 9C / 78 DA | 2-byte header, Adler-32 trailer | Yes, the decompressor auto-detects it |
| raw DEFLATE | no header | compressed data only | No: fails with incorrect header check |
| ZIP archive | 50 4B 03 04 | per-entry headers, central directory | No, it is a container of files |
| Brotli | no fixed magic | used by Content-Encoding: br | No |
| Zstandard | 28 B5 2F FD | frame header | No |
| xz | FD 37 7A 58 5A | container over LZMA2 | No |
Troubleshooting
A .gz file that gunzip opens is rejected here.
Why it happens In decompress mode the text pane expects Base64. Pasting raw binary into a textarea also destroys it, because bytes that are not valid UTF-8 are replaced before the tool ever sees them.
Fix Use the file picker for a real .gz file. Only use the text pane for data that was already Base64-encoded, which is how gzip usually travels inside JSON or a URL parameter.
Compressing a short string produces something larger than the input.
Why it happens The gzip header and trailer cost 18 bytes before any data is stored, and Base64 then adds a third. Five bytes of text become a 25-byte stream and a 36-character Base64 string.
Fix Compress the aggregate, not the item: one gzip stream over a batch of records, not one per record. As a rule of thumb, below roughly 200 bytes compression is not worth the framing.
Decompression reports a buffer error.
Why it happens The stream is truncated. A copy taken from a log viewer, a database column with a length limit, or a partially downloaded file ends before the CRC-32 and length trailer.
Fix Re-fetch the payload from the source. If the length trailer is present, gzip can prove the result is complete; a truncated stream can never be recovered past the cut.
Decompression reports an incorrect header check although the data starts with 1F 8B.
Why it happens There is extra data after the end of the stream. The decompressor treats trailing bytes as the start of another gzip member, so a log line, a newline-joined blob, or a padded field fails at that point.
Fix Trim everything after the end of the stream. Genuinely concatenated gzip members are supported and decompress into one result, which is why the extra bytes are read this way.
The result pane shows a size instead of text.
Why it happens The decompressed bytes are not valid UTF-8, which is normal for a tarball, an image, or a protobuf message. The tool refuses to render them as text rather than showing replacement characters.
Fix Download output.bin and open it with the right tool. For a .tar.gz, this step gives you the .tar, which still needs to be extracted.
When this tool is the right choice
- Measuring how much a representative payload or log sample actually shrinks before you argue about it.
- Decoding a Base64 gzip blob embedded in a JSON field, a trace header, or a URL state parameter.
- Producing a small .gz fixture for a test that reads compressed input.
- Checking whether data someone labelled gzip really is gzip, by looking at the first bytes.
When to use something else
- Packing several files together. Gzip compresses a single stream; use tar plus gzip, or a ZIP archive.
- Protecting data. Compression is not encryption and the payload is trivially recoverable.
- Predicting exactly what a CDN will send. Servers pick their own level and many now prefer Brotli, so measured sizes will differ from what you see here.
Privacy and data handling
Compression and decompression run entirely in this tab through a WebAssembly-free JavaScript implementation of zlib; no bytes leave the browser and nothing is retained after the tab closes. The practical limit is memory rather than policy: the whole input and the whole output are held at once, and the file picker rejects anything above 64 MB. Log extracts routinely contain user identifiers, so reduce the sample before pasting it.
Related developer tools
Frequently asked questions
Is gzip the same as ZIP?
No. Gzip compresses one stream and carries almost no metadata; ZIP is an archive format with a directory of entries, each compressed separately. The confusion is common because both usually use DEFLATE internally.
Why would I Base64 the compressed output?
Because compressed bytes cannot survive a JSON string, an HTTP header, or a URL parameter. Base64 makes them transportable at the cost of a third of the saving, which is still a net win for payloads of any size.
Will the output be byte-identical to gzip on the command line?
Usually not. This tool uses the default compression level and writes no modification time or original file name, while command-line gzip records both. Every gzip decompressor reads either form, and the content is identical.
Can it open a .tar.gz?
Decompressing gives you the tar stream, which is a container of files. This tool does not extract it, so download the result and unpack it with tar.
Does compressing twice make the file smaller?
No. Compressed data has almost no redundancy left, so a second pass typically adds the 18 bytes of framing and nothing else.
How large a file can I process?
The picker stops at 64 MB, and in practice large inputs are limited by the memory of the tab, since both input and output are held in full. For anything bigger, gzip on the command line streams instead.