pako

pako is a JavaScript port of zlib, the C compression library behind gzip and countless network protocols. It reimplements zlib’s deflate and inflate algorithms directly in JavaScript rather than wrapping a native binary, so the exact same code runs in browsers and in Node.js with no build step or platform-specific binaries to manage.

The project’s headline claim is binary-equivalent output: pako can produce the same deflate/gzip bytes as the reference zlib implementation, which matters for anything that needs to interoperate byte-for-byte with existing zlib/gzip tooling, not just decompress data that happens to be gzip-shaped. Performance is close to native zlib in modern JS engines, and the minified bundle is small (under 15K gzipped for the full build, with smaller deflate-only and inflate-only builds available for size-sensitive browser code).

pako exposes both simple one-shot helpers (deflate/inflate/gzip/ungzip) for small buffers and streaming Deflate/Inflate classes for chunked processing of larger data, mirroring the ergonomics of Node’s built-in zlib module while working in environments where that module isn’t available.

What You Get

• One-shot helper functions (deflate, inflate, deflateRaw, inflateRaw, gzip, ungzip) for compressing or decompressing an entire buffer in one call
• Streaming Deflate and Inflate classes that accept data in chunks via .push(), for processing large payloads without holding everything in memory at once
• Binary-equivalent output to reference zlib, so compressed data interoperates byte-for-byte with server-side gzip/zlib tooling
• Separate deflate-only and inflate-only browser bundles (in addition to the full bundle) to keep client-side payload size down
• Built-in UTF-8 string handling — deflate auto-detects string input and encodes it, and inflate can decode straight back to a JavaScript string with toText: true
• Support for zlib’s advanced options (dictionaries, window bits, memory level, compression strategy) for callers who need fine-grained control

Common Use Cases

• Compressing data client-side in the browser before sending it to a server, where a native zlib binding isn’t available
• Decompressing gzip- or deflate-encoded API responses or file formats inside a browser or edge/serverless runtime with no native module support
• Building tools that must produce or consume zlib/gzip streams that are byte-identical to what standard zlib produces (e.g. testing, format compatibility, or environments that verify checksums against a reference implementation)
• Streaming compression/decompression of large files in chunks to avoid loading an entire payload into memory
• Compressing JSON payloads (e.g. JSON.stringify output) before storage or transmission, then inflating them back into JavaScript objects

Under The Hood

Architecture

pako is organized as a thin public API (src/index.ts, src/deflate.ts, src/inflate.ts) layered directly on top of a faithful JavaScript port of zlib’s internal C sources under src/zlib/ (deflate.mjs, inflate.mjs, inftrees.mjs, inffast.mjs, trees.mjs, adler32.mjs, crc32.mjs, zstream.mjs, gzheader.mjs, constants.mjs), mirrored one-to-one against zlib’s own module boundaries specifically to keep the port maintainable and behaviorally identical to upstream zlib. The public Deflate/Inflate classes and one-shot helper functions wrap a ZStream object and drive it through the low-level zlibDeflate*/zlibInflate* functions exported from src/zlib.mjs, handling chunk accumulation, dictionary application, and UTF-8 string coercion so callers never touch the zlib-level state machine directly; nothing else in the tree can change without touching this same layering, since every public entry point ultimately funnels through the same ZStream-driven core.

Tech Stack

The library is written in TypeScript (compiled with a strict tsconfig.json targeting ESNext modules) with a .mjs-suffixed internal zlib port that ships as part of the package, avoiding any native addon or WASM dependency. The build pipeline uses Rollup (rollup-plugin-dts for type bundling) via a custom support/build-dist.mjs script to produce CommonJS, ESM, and minified browser UMD bundles from a single source tree, with vite used for local example/dev tooling and typedoc generating published API docs. Linting runs through ESLint 9 with the neostandard shareable config, and the package publishes typed .d.ts definitions alongside every build target.

Code Quality

Tests live under test/ and run via Node’s built-in node:test runner (deflate.test.mjs, inflate.test.mjs, chunks.test.mjs, strings.test.mjs, gzip_specials.test.mjs, dist.test.mjs), asserting output against Node’s native zlib module and fixture files under test/fixtures/ to validate binary-equivalence claims directly rather than only checking round-trip correctness. The npm test script chains linting, a full build, a TypeScript type-check (tsc --noEmit), and the test run together, and c8 provides coverage reporting; CI (.github/workflows/ci.yml) runs this same suite on every push and pull request plus a weekly scheduled run. TypeScript’s strict mode and consistent zlib-derived naming conventions across the low-level modules keep the port’s internals easy to cross-reference against upstream C zlib.

API Design pako’s public surface stays close to Node’s built-in zlib module and to common JS async idioms, so developers already familiar with server-side gzip handling can adopt it with almost no new concepts: one-shot functions for simple cases, streaming classes with a .push(chunk, isLast) pattern for large data, and automatic string/UTF-8 handling that removes a common source of encoding bugs. Documentation is dense but thorough for a small library — the README covers install, both API styles, dictionary usage, and string handling with runnable examples, and generated TypeDoc API docs are published separately for full option-by-option reference.