How to use the Gzip Decompress
Decompress gzip data in two steps:
1
Paste encoded gzip data or upload a .gz file
Paste the Base64 or hex output from the Gzip Compress tool, or click 'Upload .gz' to load a gzip binary. The input format auto-detects between Base64 and hex.
2
Click Decompress Gzip
The tool validates the gzip magic bytes (0x1F 0x8B), decompresses the data using fflate, and displays the original text. Stats show compressed size, recovered size, and expansion ratio.
When to use this tool
Use the Gzip Decompressor to recover text from gzip-compressed data:
- →Decompressing gzip-encoded API responses or database exports stored as Base64 strings to read their JSON or text content
- →Expanding .gz log files to inspect their content without installing local gzip tools
- →Verifying that a gzip-compressed payload produced by the companion Gzip Compress tool round-trips correctly to the original text
- →Decoding Base64-encoded gzip data embedded in configuration files, environment variables, or deployment scripts
- →Decompressing Content-Encoding: gzip responses captured from network traffic analysis tools (Wireshark, Fiddler, DevTools) that export as Base64 or hex
- →Expanding gzip-compressed fixtures from test suites to inspect their content while debugging integration tests
Frequently asked questions
Q:What does the 'Not valid gzip data — missing magic bytes 0x1F 0x8B' error mean?
Every gzip file starts with two specific identifier bytes: 0x1F (decimal 31) and 0x8B (decimal 139), called magic bytes. These bytes identify the file as gzip format before any decompression attempt. If your input doesn't decode to bytes starting with 0x1F 0x8B, the data is not a valid gzip stream — common causes: (1) you pasted raw DEFLATE data instead of gzip-wrapped data — use a zlib or raw DEFLATE decompressor instead; (2) the Base64 or hex has been corrupted or truncated; (3) the data is compressed with a different algorithm (Brotli, zlib, LZ4, Snappy); (4) the input is not compressed at all. A valid Base64 gzip always starts with H4sI when unpadded or H4sI when padded.
Q:How does auto-detection work between Base64 and hex input?
The auto-detector inspects the input string (after stripping whitespace) and checks whether all characters are valid hexadecimal digits (0–9, a–f, A–F) and the character count is even. If both conditions are true, it treats the input as hex. Otherwise it treats it as Base64. This heuristic works reliably in practice because Base64 strings contain letters G–Z/g–z and the + and / characters, which are not valid hex digits. Edge case: a Base64 string that happens to contain only hex characters (rare in practice) will be misidentified as hex — use explicit 'Base64' mode if auto-detect gives a wrong result.
Q:Can I decompress a .gz file directly without converting it to Base64 first?
Yes — click the 'Upload .gz' button and select a .gz file from your filesystem. The tool reads the binary file using FileReader.readAsArrayBuffer (which preserves every byte faithfully), converts it to Base64 internally, and automatically populates the input field and switches to Base64 mode. Then click Decompress Gzip to recover the original content. This works for any valid RFC 1952 gzip file — from nginx pre-compressed .gz files, gunzip'd archives, Node.js zlib.gzip output, Python's gzip.compress, or any other standard gzip producer.
Q:Why does the tool show an expansion ratio instead of a savings percentage?
When decompressing, you're going from a smaller compressed file to a larger original file, so an 'expansion ratio' (decompressed / compressed) is more intuitive than a savings percentage. An expansion ratio of 3.5× means the decompressed content is 3.5 times larger than the compressed input — which corresponds to about 71% compression savings when going the other direction. High expansion ratios (5×–20×) indicate very compressible input like repetitive logs, template HTML, or minified-then-gzipped CSS. Low expansion ratios (1.1×–1.5×) suggest the input was already compact, partially random, or is a binary format compressed at low level.
Q:What happens if the decompressed content is binary, not UTF-8 text?
The tool uses fflate's strFromU8 to convert the decompressed bytes to a JavaScript string — this function uses UTF-8 decoding. If the gzip content is binary data (an image, an executable, or non-UTF-8 text), the UTF-8 decoder may throw on invalid byte sequences or produce garbled output with replacement characters (U+FFFD). This tool is designed for decompressing gzip-compressed text content. For binary gzip content, use a dedicated binary analysis tool or download the original .gz and decompress with native gunzip — the terminal's output goes to stdout as raw bytes that can be piped to other binary tools.
Q:Can I decompress multi-member or concatenated gzip streams?
A multi-member gzip stream is a file containing multiple independent gzip compressed streams concatenated end-to-end — this is a valid use of the gzip format per RFC 1952 (gzip implementations must handle multi-member files). fflate's gunzipSync correctly handles multi-member gzip streams by decompressing each member in sequence and concatenating the results. This is common with log rotation tools (logrotate) that append new gzip members rather than rebuilding the entire file. The decompressor processes all members transparently — you get the complete concatenated decompressed content without needing to split the file manually.