{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}

Auto detect resolves the source representation; a pinned format bypasses detection.
Use one payload at a time. Binary gzip files are converted to editable Base64 locally.
{{ sourceMeta }}
{{ sourceActionHint }}
Auto detect reports both the requested and resolved wrapper in the result audit.
Choose strict UTF-8 when replacement characters could hide corrupted text.
{{ workflowFeedback }}
This optional ledger row reports replacement characters without changing decoded output.
{{ params.report_replacements ? 'Enabled' : 'Disabled' }}
{{ decodedOutput }}
MetricValueMeaningCopy
{{ row.metric }}{{ row.value }}{{ row.detail }}
SignalValueEvidenceCopy
{{ row.signal }}{{ row.value }}{{ row.evidence }}
Gzip Compression Checker Check a public URL or pasted headers for gzip, Brotli, or identity compression with cache-variation checks and measured byte savings.
Base64 Encoder and Decoder Encode or decode Base64 text and files locally, choose standard or URL-safe output, repair missing padding, and inspect the recovered bytes.
Text Hash Generator Hash exact UTF-8 text in your browser with SHA-2 or SHA-3 and verify byte counts, salt rules, and fixed-width digests before comparison.
Application Programming Interface (API) Testing Tool Test HTTP APIs from your browser with cURL import and authentication while inspecting exposed headers, timing, response text and CORS failures.

Compressed text usually arrives as bytes, not as readable characters. When those bytes must travel through JSON, logs, forms, or copied messages, they are often written as Base64, Base64URL, hexadecimal pairs, or escaped byte sequences. Recovering the original text therefore requires more than one kind of decoding.

Source representation
How compressed bytes are written as text, such as Base64 or hexadecimal.
Deflate stream
The compressed bit stream containing stored blocks or Huffman-coded literals and back-references.
Wrapper
Metadata and integrity fields around deflate. Gzip and zlib use different headers and checksums; raw deflate has neither wrapper.
Text encoding
The rule that turns inflated bytes into characters, such as UTF-8, UTF-16, or Latin-1.

These distinctions explain common failures. A valid Base64 string can still contain the wrong compression wrapper. A correctly inflated byte stream can still be invalid UTF-8. Conversely, unreadable Base64 is not evidence of corruption because it may be a faithful text representation of binary gzip data.

Decompression should be bounded because a small compressed input can expand into a much larger output. Integrity checks can detect damaged gzip or zlib data, but successful decompression does not establish that the resulting text is safe, complete, or from a trusted source.

How to Use This Tool:

Identify the representation, wrapper, and expected character encoding as separately as the available evidence allows.

  1. Paste one payload or load one file. A local gzip file up to 8 MiB is converted to editable Base64 in the browser; editable source is limited to 12 MiB of text.
  2. Choose the input format. Leave Auto detect for clear hexadecimal notation or ordinary Base64/Base64URL, and pin a format when the copied text is ambiguous.
  3. Select the compression wrapper. Auto detection tries a header-led bounded sequence; pin Gzip, Zlib, or Raw deflate when the producer specifies it.
  4. Choose the decoded output. Start with UTF-8, use strict UTF-8 when replacement characters could hide damage, or switch to the bounded byte preview when the inflated content may not be text.
  5. Check the resolved format, wrapper evidence, and text status before copying or downloading the decoded result.

Interpreting Results:

A readable output is strongest when the resolved wrapper matches the expected producer, the wrapper checksum passes, and the selected text encoding reports a valid result.

  • Resolved input format describes how the source text became bytes. It is independent of the compression wrapper.
  • UTF-8 valid or Strict UTF-8 valid confirms character decoding. Replacement characters in non-strict UTF-8 indicate invalid byte sequences were substituted.
  • Expansion ratio compares inflated bytes with compressed bytes. It can be below 1 for very small payloads because wrapper and coding overhead exceed the original content.
  • A raw-deflate result has no wrapper checksum to confirm. Compare it with the expected producer and content structure before trusting it.

Technical Details:

Deflate represents data as a sequence of final or non-final blocks. Blocks can store literal bytes directly or use fixed or dynamic Huffman codes for literals, lengths, and backward distances. Each back-reference copies already-inflated bytes, which is why output size must be checked throughout decompression rather than only at the end.

Transformation Core:

The complete path separates representation decoding, wrapper validation, deflate inflation, and character decoding.

Stage What happens What can stop the result
RepresentationBase64, Base64URL, hex, or escaped text becomes bytesInvalid alphabet, padding, trailing bits, or incomplete byte pairs
WrapperGzip or zlib header fields are separated from deflate; raw uses all bytes directlyBad magic, reserved flags, truncation, or unsupported zlib preset dictionary
DeflateStored, fixed-Huffman, or dynamic-Huffman blocks produce bytesInvalid trees, codes, lengths, distances, or output above 16 MiB
IntegrityGzip CRC-32 and ISIZE or zlib Adler-32 are compared with inflated bytesChecksum or size mismatch
CharactersInflated bytes become text or a hexadecimal/ASCII previewInvalid strict UTF-8 or odd UTF-16 byte count

Wrapper Rule Core:

Wrapper Leading evidence Integrity evidence Notable limit
Gzip1F 8B 08 and a valid flag byteCRC-32 plus uncompressed size modulo 232One complete gzip member is interpreted
ZlibDeflate method and header divisible by 31Adler-32Preset-dictionary streams are rejected
Raw deflateNo wrapper bytesNo wrapper checksumMust be identified by producer context or successful inflation

Auto wrapper detection tries gzip first when gzip magic is present, zlib first when its header check matches, and raw deflate first otherwise. If the first attempt fails, the other supported wrappers are tried within the same bounded set. Pinning a wrapper disables that fallback and makes a mismatch an error.

Formula Core:

The size comparison reports inflated bytes divided by compressed bytes. It uses the decoded compressed byte count, not the length of the Base64 or hexadecimal text.

E = Binflated Bcompressed

E is the expansion ratio. Both byte counts remain exact; the visible ratio uses two decimal places below 10 and one decimal place at 10 or above.

Byte preview shows at most 1,024 inflated bytes. The full decompressed output remains capped at 16 MiB. Non-strict UTF-8 inserts one Unicode replacement character for each invalid byte it encounters, while strict UTF-8 rejects the result instead.

Privacy and Accuracy Notes:

Payloads and local files are decoded in the current browser tab. No decompression request is submitted to a server.

  • A decompression limit protects browser responsiveness but means a valid stream above 16 MiB cannot complete here.
  • Gzip and zlib checksum success detects many accidental changes; it is not a cryptographic authenticity check.
  • Raw deflate and permissive character decoding provide less evidence. Keep the expected wrapper and text encoding fixed when comparing repeated results.

Worked Examples:

A tiny gzip payload

The Base64 value H4sIAAAAAAAC/8tIzcnJBwCGphA2BQAAAA== resolves to a 25-byte gzip stream and inflates to the five-byte UTF-8 text hello. The CRC-32 and size trailer pass, while the expansion ratio is 0.20 because gzip overhead is larger than this very short message.

References: