Gzip Text Decompressor

Decompression failed

Input format:

Auto detect resolves Base64, Base64URL, and clear hex dumps; pinned formats bypass source detection.

Compression wrapper:

Auto detect resolves gzip, zlib, or raw deflate from the decoded bytes; pinned wrappers bypass wrapper detection.

Compressed payload:

Paste one compressed payload. Auto detect uses the format and wrapper controls above; pinned modes bypass detection.

Decoded output:

Choose strict UTF-8 when a replacement character would hide corrupted text.

{{ decodedOutput }}

Metric	Value	Detail	Copy
{{ row.metric }}	{{ row.value }}	{{ row.detail }}

Signal	Value	Evidence	Copy
{{ row.signal }}	{{ row.value }}	{{ row.evidence }}

Fix the compressed payload to render byte expansion bars.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Compressed text usually reaches people after it has been wrapped twice. First, binary compressed bytes are turned into a printable carrier such as Base64, Base64URL, a hex dump, or escaped bytes. Then the compressed bytes themselves may be framed as gzip, zlib, or bare DEFLATE data. Reading the message correctly means undoing both parts in the right order before choosing a character encoding for the recovered bytes.

That distinction matters in everyday debugging. A copied response body from an API trace can begin with H4sI because gzip bytes were Base64-encoded. A log field can start with 78 9c because a zlib stream was written as hex. A queue payload can inflate successfully and still look wrong because the result is UTF-16, Latin-1, binary data, or a serialized record rather than UTF-8 text.

Printable carrier: Base64, URL-safe Base64, hex pairs, and escaped-byte strings let binary compressed data pass through text-only fields.
Compression wrapper: Gzip and zlib add recognizable framing around DEFLATE blocks; raw deflate has no header or trailer bytes.
Text encoding: Inflated bytes become readable only after a decoder such as UTF-8, strict UTF-8, UTF-16, Latin-1, or byte preview is chosen.

Compressed text passes from a printable carrier into a byte stream, through gzip, zlib, or raw deflate decompression, and then into decoded text or a byte preview.

The most common false positive is a readable-looking output that came from the wrong assumption. Non-strict UTF-8 can replace damaged bytes, raw deflate can succeed without any wrapper proof, and a short copied value can fail only after the compressed blocks are tested. Wrapper evidence and byte counts help separate a bad carrier from a bad compression stream and from a bad text interpretation.

Decompression also does not make content safe. A recovered log, token, request body, or serialized value may contain credentials, personal data, shell text, or binary bytes that should not be shared. Treat the decoded message as recovered evidence, then verify the source, wrapper, size, and text status before using it elsewhere.

How to Use This Tool:

Follow the same order as the payload itself: load the visible carrier, resolve the compression wrapper, choose a text decoder, then confirm the evidence before copying the result.

Paste the value into Compressed payload, drop text onto the field, or select Browse file. One local file is read; files larger than 8 MB are rejected before browser-side decompression.
Choose Input format. Auto detect recognizes clear hex dumps first, then Base64 or Base64URL. Pick Hex for byte pairs such as 1f 8b 08 00, or Escaped bytes for \x1f\x8b and percent-escaped byte strings.
Set Compression wrapper. Leave Auto detect on when the producer is unknown, or pin Gzip, Zlib, or Raw deflate when you want a claimed format to fail if the bytes disagree.
Select Decoded output. Start with UTF-8 for JSON, logs, and modern API text. Use Strict UTF-8 when replacement characters would hide corruption, and use Byte preview when the inflated data may be binary.
Review the summary badges and the red error alert. If Decompression failed appears, switch from auto to the carrier you can prove from the copied value, then test the expected wrapper again.
Base64 alphabet errors, odd hex digit counts, wrapper mismatches, and strict text failures point to different fixes. Change only one setting at a time when you need repeatable evidence.
Read Decoded Text, then compare Byte Evidence and Wrapper Evidence. Use Payload Size Bars when compressed and decompressed byte counts need to be shown in a handoff note.

Interpreting Results:

A successful run proves that the selected bytes could be inflated under the resolved wrapper. It does not prove that the payload was copied in full, that the content is harmless, or that the decoded characters match the producer's original intent. Confirm the wrapper, byte counts, and strict text status before treating the displayed text as final.

Gzip text decompression result cues and checks
Result Cue	Meaning	Verification Check
Decoded Text is readable	The carrier decoded, the wrapper inflated, and the selected character encoding produced displayable characters.	Compare the resolved input format, resolved wrapper, strict UTF-8 check, and byte counts with the original source.
Strict UTF-8 check is invalid	The inflated bytes are not valid UTF-8, or the content is not plain UTF-8 text.	Switch to Byte preview before trying UTF-16 or Latin-1, and avoid copying text that contains unexplained replacement characters.
Raw deflate resolves	The DEFLATE blocks inflated without gzip or zlib framing.	Confirm the source really emits raw deflate, because no wrapper header, trailer, CRC-32, ISIZE, or Adler-32 field is available.
Trailer CRC-32 and Trailer ISIZE appear	Gzip supplied trailer evidence for accidental corruption and original size modulo 2^32.	Use those values as integrity clues, not sender authentication or content safety proof.
Expansion ratio is unusually high	A small compressed byte stream expanded into far more recovered data.	Inspect the recovered byte count and content before forwarding the result, especially from untrusted tickets, logs, or queues.

Wrong-format failures are useful when they expose a bad assumption. Pinning Gzip or Zlib can prove that a producer's label is wrong, while auto mode is better for first-pass discovery when the source format is unknown.

Technical Details:

DEFLATE represents data as blocks containing literal bytes, length-distance back references, and Huffman-coded symbols. Gzip and zlib both use DEFLATE for the compressed body, but they frame it differently. Gzip is a member format with fixed identification bytes, optional metadata fields, and a CRC-32 plus ISIZE trailer. Zlib has a short CMF/FLG header and an Adler-32 check value. Raw deflate keeps only the compressed blocks, so fewer independent checks remain after inflation succeeds.

Carrier decoding is separate from decompression. Base64 padding repair, URL-safe alphabet conversion, hex-pair normalization, and escaped-byte parsing only recover the compressed bytes. The wrapper test then determines whether those bytes should be read as gzip, zlib, or raw deflate before any text decoder is applied.

Transformation Core:

Each transformation has a different failure shape. Keeping the stages distinct makes it easier to decide whether to recopy the visible value, switch wrappers, or change the output encoding.

Compressed text transformation stages and failure modes
Stage	Accepted Input	Output of the Stage	Failure to Check
Carrier to bytes	Base64, Base64URL, hex byte pairs, escaped bytes, or one loaded local file	The printable value becomes the compressed byte stream.	Invalid alphabet, bad padding, odd hex count, copied labels, or missing byte escapes.
Wrapper resolution	Gzip, zlib, or raw deflate	The correct framing rules are applied before inflation.	Testing zlib bytes as gzip, or expecting checksum evidence from raw deflate.
Inflate	Valid DEFLATE block data for the selected wrapper	Original bytes are recovered from compressed blocks.	Truncated input, damaged block data, failed integrity check, or a missing preset dictionary.
Text decode	UTF-8, strict UTF-8, UTF-16LE, UTF-16BE, Latin-1, or byte preview	Recovered bytes are displayed as text or a hex-and-ASCII byte view.	Binary content, encrypted content, or a wrong character encoding that produces misleading characters.

Wrapper Evidence:

Gzip zlib and raw deflate wrapper evidence
Wrapper	Recognition Clue	Evidence Available	Important Limit
Gzip	Starts with `1F 8B`; method byte `08` means DEFLATE.	Flags, optional name/comment fields, modification time, OS byte, trailer CRC-32, and trailer ISIZE may be visible.	Optional fields are often empty, and CRC-32 does not authenticate who created the content.
Zlib	CMF and FLG identify the compression method and pass the modulo-31 header check.	The header gives method and window-size clues; the stream format includes Adler-32 validation.	The header is compact, so a valid-looking start still needs a successful inflate.
Raw deflate	No wrapper bytes are required.	Only successful DEFLATE inflation and the recovered byte count remain.	No wrapper checksum, original-size trailer, timestamp, or metadata is available.

Formula Core:

The expansion ratio compares recovered bytes with the compressed byte stream after the printable carrier has been decoded.

expansion_ratio = \frac{decompressed_bytes}{compressed_bytes}

For example, 94 compressed bytes that inflate to 154 bytes produce 154 / 94, or about 1.64x. Ratios below 10x are shown with two decimal places; ratios of 10x or more use one decimal place.

The compressed share expresses the compressed byte count as a percentage of recovered bytes.

compressed_share = \frac{compressed_bytes}{decompressed_bytes} \times 100

Byte counts and character counts are different. UTF-8, UTF-16LE, UTF-16BE, and Latin-1 can display different character counts from the same bytes, while byte preview intentionally limits the view to byte-oriented evidence instead of claiming that the recovered data is text.

Privacy and Accuracy Notes:

The pasted payload and selected file are decoded and inflated in the browser rather than sent to a remote decompression service. The page may need to load its decompression and chart code before work can run, so local processing should still be used in a trusted browser session.

Only one selected file is read, and files larger than 8 MB are rejected before loading.
Small compressed data can expand into much larger recovered text, so inspect high expansion ratios before using the output elsewhere.
Strict UTF-8 failure means the recovered bytes are not valid UTF-8 text; it does not automatically mean inflation failed.
Raw deflate provides less independent evidence than gzip or zlib because it has no wrapper checksum or trailer metadata.
Decoded logs, API bodies, and tokens can contain credentials or personal data. Review the recovered content before sharing it.

Worked Examples:

These cases show how the visible payload, wrapper evidence, and text status should agree before the decoded output is trusted.

API log value beginning with H4sI

A copied field beginning with H4sI is often Base64 text carrying gzip bytes. Leave Input format and Compression wrapper on Auto detect, then keep Decoded output on UTF-8. A strong result shows gzip in Wrapper Evidence, readable JSON or log text in Decoded Text, and byte counts that match the incident note you are preparing.

Hex trace starting with 78 9c

A command-line trace that starts with 78 9c and continues as byte pairs is a common zlib clue. Choose Hex and pin Zlib to test that claim. Success should show Zlib CMF and Zlib FLG; failure usually means the trace was truncated, copied from inside another protocol frame, or mislabeled.

Inflated bytes with invalid strict UTF-8

A payload may inflate while Strict UTF-8 check reports invalid. Switch Decoded output to Byte preview and inspect the first bytes before trying UTF-16 or Latin-1. Do not copy a decoded string with unexplained replacement characters unless the byte preview also matches the expected content.

FAQ:

Why did auto detect choose Base64?

Auto detect looks for explicit hex clues first, then reads the value as Base64 or Base64URL. Choose Hex when the payload is byte pairs with separators, or Escaped bytes when it contains \xNN or percent escapes.

When should I force gzip, zlib, or raw deflate?

Force a wrapper when the producer claims a format and you need to test that claim. Auto detect is better for discovery because it tries likely wrappers from the leading bytes and can still fall back to raw deflate.

Why did decompression work but the text looks broken?

The recovered bytes may be binary, encrypted, serialized, or written in another character encoding. Check Byte preview and Strict UTF-8 check before switching to UTF-16 or Latin-1.

Does gzip trailer evidence prove the content is safe?

No. CRC-32 and ISIZE help detect accidental corruption in a gzip member, but they do not identify the sender, prove the source was trusted, or make recovered text safe to run or share.

Are selected files uploaded?

No selected payload is uploaded for decompression. A local binary file is read in the browser and converted into editable Base64 text when it looks like gzip, a binary file, or an octet-stream file.

Glossary:

DEFLATE: The compressed block format used inside gzip and zlib streams.
Gzip: A member format with identification bytes, optional header fields, DEFLATE data, and a CRC-32 plus ISIZE trailer.
Zlib: A compact wrapper around DEFLATE data with CMF and FLG header bytes and an Adler-32 check value.
Raw deflate: A DEFLATE stream without gzip or zlib wrapper bytes.
ISIZE: The gzip trailer field that stores the original uncompressed size modulo 2^32.
Base64URL: A URL-safe Base64 variant that uses - and _ instead of + and /.

References:

RFC 1952: GZIP File Format Specification version 4.3, IETF, May 1996.
RFC 1950: ZLIB Compressed Data Format Specification version 3.3, RFC Editor, May 1996.
RFC 1951: DEFLATE Compressed Data Format Specification version 1.3, RFC Editor, May 1996.
Encoding Standard, WHATWG.
TextDecoder: fatal property, MDN Web Docs.
How to use compression when downloading with cURL, Simplified Guide.