Zlib Compress Online — Text to Deflate Base64

Compress text into RFC 1950 zlib (deflate) base64 — the same format used by PNG, Git, JAR, and MySQL COMPRESS. Browser-native CompressionStream, 100% client-side.

Input Text

Zlib Base64 Output

Zlib vs Deflate vs Gzip — three names, one algorithm

DEFLATE (RFC 1951) is the compression algorithm itself — LZ77 plus Huffman coding, no header. Zlib (RFC 1950) wraps DEFLATE with a 2-byte header and a 4-byte Adler-32. Gzip (RFC 1952) wraps DEFLATE with a 10-byte header (with optional metadata) and a CRC-32 + ISIZE trailer. The browser's CompressionStream('deflate') produces RFC 1950 zlib — for raw RFC 1951 use deflate-raw.

This tool emits the zlib (RFC 1950) wrapper, which is what most server-side libraries default to when you call zlib.compress() in Python or zlib.deflateSync() in Node.

How to compress text with zlib — 4 steps

Paste your text. Drop SVG, XML, JSON, or log lines into the Input panel. Click Load Sample for a demo SVG.
Click Compress. The browser streams your text through the native zlib encoder and emits compressed bytes.
Read the ratio. Stats show original bytes, compressed bytes, and percent saved. Repetitive text usually shrinks 60–85%.
Copy the base64. Use the Copy button to send the result to your clipboard. Paste it into PNG chunks, database columns, JSON values, or test fixtures.

Sample input & output

Input — XML snippet

<config><server><host>api.example.com</host><port>443</port></server></config>

Output — zlib base64 (≈ 45% smaller)

eJxLLU4t0lAyULJSUMpLzU0tSk0tSiyJVdJRyk0sUMjMzdHITEnNK1FILCotzs9LzcssAQDOHQzo

RFC 1950 Compliant

Output is standard zlib — accepted by Python zlib.decompress, Node zlib.inflate, Java Inflater, MySQL UNCOMPRESS, and PNG decoders.

Native Browser Engine

Built on CompressionStream — no JavaScript pako or zlib library bundled. Compresses megabytes in milliseconds.

Zero Network

Text is processed inside the page. Verify in DevTools Network tab — no requests fire when you click Compress.

Common use cases

check_circleGenerating zlib payloads for HTTP Content-Encoding: deflate
check_circleProducing test fixtures for zlib decompression in unit tests
check_circleCompressing data before MySQL COMPRESS() or PostgreSQL bytea storage
check_circleEmbedding compressed SVG inside data: URIs to shrink page weight
check_circleReducing payload size in WebSocket messages and Server-Sent Events
check_circleShrinking log batches before forwarding to S3, Loki, or Splunk
check_circleBuilding PNG image chunks (zlib is mandated inside IDAT)
check_circleCompressing strings for QR codes, URL fragments, or short links

Gzip vs Brotli vs Deflate — pick wisely

Format	Wrapper	Overhead	Best For
zlib (deflate)	2-byte header + Adler-32	6 bytes	PNG, Git, JAR, embedded payloads
deflate-raw	none (RFC 1951)	0 bytes	ZIP entries, tightest possible payload
gzip	10-byte header + CRC-32	18 bytes	Files, HTTP, ubiquitous CLI tooling
brotli	custom	few bytes	HTTPS to modern browsers, best ratio

Need to decompress instead?

Reverse the operation, switch to gzip, or chain compression with format and minify tools.

Zlib Decompress Gzip Compress JSON Minifier

Frequently Asked Questions

What is zlib compression?

Zlib (RFC 1950) is a thin 6-byte wrapper around the DEFLATE algorithm: a 2-byte header that signals the compression method and window size, followed by raw DEFLATE bytes, ending with a 4-byte Adler-32 checksum. It is the format used by PNG image chunks, Git object storage, Java JAR/ZIP entries, and the MySQL COMPRESS() function.

Why does the browser API call it deflate?

The Compression Streams spec uses the name deflate to mean "DEFLATE wrapped in zlib" (RFC 1950) — confusingly, this matches HTTP's Content-Encoding: deflate header, which most servers also implement as zlib. For raw RFC 1951 DEFLATE without any wrapper, use the deflate-raw format instead. This tool intentionally uses deflate (zlib) because it is the most interoperable.

Should I use gzip or zlib?

Use gzip when producing files (.gz), HTTP responses, or anything that will be decompressed by gunzip / standard CLI tools — it carries metadata and a CRC-32. Use zlib when storing compressed bytes inside another container (PNG, Git, JAR) where the surrounding format already handles framing — its 6-byte overhead is smaller than gzip's 18 bytes.

How does this tool work without a server?

Modern browsers ship CompressionStream (Chrome 80+, Firefox 113+, Safari 16.4+). The tool wraps your text in a Blob, pipes it through new CompressionStream("deflate"), and base64-encodes the resulting bytes — all locally in JavaScript.

How small will my data get?

Highly repetitive text (JSON with the same keys, XML, SVG, log lines) typically shrinks 60–85%. Random data (PNG pixels, encrypted blobs) does not compress because there is no redundancy. Small payloads under ~30 bytes can grow slightly because the 6-byte zlib overhead exceeds the savings.

Can Python or Node decompress this output?

Yes. In Python: import zlib; zlib.decompress(base64.b64decode(payload)). In Node.js: zlib.inflateSync(Buffer.from(payload, "base64")). In Java: java.util.zip.Inflater. The output is fully RFC 1950-compliant.

Is the input uploaded?

No. CompressionStream runs inside the browser process. Open DevTools Network tab and click Compress — you will see no requests fire. Sensitive payloads, secrets, and proprietary data never leave your device.

Why is my output base64 instead of raw bytes?

Compressed output is binary and contains bytes that cannot survive copy-paste, JSON encoding, or HTTP headers. Base64 turns the bytes into a 7-bit ASCII string that can be embedded anywhere — environment variables, JSON, URL parameters, YAML — without corruption.