What this tool does
It compresses pasted text into Base64-encoded bytes using supported browser compression formats such as Gzip and Deflate.
It decompresses Base64-encoded compressed payloads back into readable text when the selected format is supported.
It reports input size, output size, and compression ratio so payload changes are easy to compare.
It detects native browser support and gives an explicit unsupported-state message instead of silently dropping Brotli or other unavailable formats.
Typical use cases
- Inspect compressed HTTP payload samples copied from debugging tools.
- Estimate how much JSON, HTML, CSS, or log snippets shrink under Gzip before transport.
- Decode Base64-wrapped compressed fixtures used in tests or documentation.
- Compare Gzip and Deflate behavior without invoking command-line tools.
- Validate whether the current browser runtime exposes Brotli compression support.
Input examples
JSON payload
{ "event": "cache_miss", "path": "/api/users", "durationMs": 184 }Base64 gzip
H4sIAAAAAAAA/8tIzcnJVyjPL8pJAQBSntaLCwAAAA==
HTML snippet
<main><h1>Status</h1><p>Cache miss</p></main>
Output examples
Compressed output
Base64-encoded compressed bytes ready for copying.
Decompressed text
Readable payload recovered from a Base64 compressed input.
Size summary
Input 1.2 KB, output 420 B, ratio 0.35x
Common errors and fixes
Pasting plain text while decompressing
Switch to compress mode, or paste Base64-encoded compressed bytes for decompression.
Expecting Brotli everywhere
Check the browser support status; Brotli depends on native CompressionStream('br') support.
Confusing Base64 size with raw compressed byte size
Use the size summary for byte counts and remember Base64 adds transfer overhead.
Choosing the wrong decompression format
Match the format to the original encoder: Gzip input must be decoded as Gzip.
Testing binary files as pasted text
This MVP focuses on text and Base64 payloads, not arbitrary binary file uploads.
Security and privacy notes
For the shared privacy terminology, local processing model, external-request labels, and DevTools verification workflow, see the Trust Center.
- Compression and decompression use browser APIs and stay local to the page.
- Avoid pasting production payloads that still contain secrets before redaction.
- Unsupported formats are reported explicitly so no payload is silently transformed incorrectly.
Step-by-step workflow
- Feed Gzip/Brotli Lab the smallest reproducible sample you can collect from the real issue.
- Review the first findings and separate confirmed signals from assumptions or environment-specific noise.
- Compare a clean baseline sample against the problematic input when you need to isolate regressions.
- Keep one redacted output snapshot with the key findings for tickets, runbooks, or incident handoff.
Quality checklist before sharing output
- Confirm Gzip/Brotli Lab findings still reproduce with the same input and assumptions.
- Check that the sample includes enough surrounding context to support the conclusion you are drawing.
- Translate notable findings into concrete next checks, ownership, or remediation notes.
- Redact private hosts, tokens, certificates, or customer identifiers before sharing analysis output.
Operational notes
Gzip/Brotli Lab is most effective when it produces a focused, reproducible evidence bundle that can be handed to the next engineer without extra cleanup.
Frequently asked questions
Why is compressed output Base64?
Compressed bytes are binary, so Base64 makes them safe to copy through text fields.
Does Brotli always work?
No. Brotli support depends on the browser runtime exposing native CompressionStream support for br.
Can I decompress a Gzip response body?
Yes, if you paste the compressed bytes as Base64 and select Gzip decompression.
Does this call a server?
No. The operation is performed in the browser.
Why can Base64 output look larger than input?
Small inputs and Base64 overhead can outweigh compression savings.
