crc-32

crc-32 is a small, dependency-free JavaScript implementation of the standard CRC-32 checksum algorithm, plus a parallel CRC-32C (Castagnoli) variant, built by SheetJS for use across Node.js, bundlers, and legacy browsers back to IE6. It exposes three tiny functions — buf, bstr, and str — for hashing byte arrays, binary strings, and UTF-8 JS strings respectively, all returning a signed 32-bit integer with support for rolling/incremental CRCs via an optional seed argument.

Despite its size, the library is heavily exercised in production: it sits underneath SheetJS’s own xlsx parser (used to validate ZIP/OOXML data integrity) and is pulled in by a huge swath of the npm ecosystem for anything that needs a fast, portable checksum — file integrity checks, cache-busting, dedup keys, and ZIP-format handling. It ships both CommonJS and ESM builds, hand-written TypeScript declarations, and a standalone CLI binary for computing checksums from the command line.

What You Get

• Three focused functions — CRC32.buf, CRC32.bstr, CRC32.str — for hashing byte arrays, binary strings, and UTF-8 strings
• A parallel CRC32C (Castagnoli) implementation available from the crc-32/crc32c subpath
• Rolling/incremental checksum support via an optional seed argument, so large inputs can be hashed in chunks
• Dual CommonJS (crc32.js) and ESM (crc32.mjs) builds selected automatically via package.json exports
• Hand-written, dtslint-verified TypeScript declarations
• A standalone crc32 CLI binary for computing checksums from files or stdin, with signed/unsigned/hex output formats

Common Use Cases

• Validating file or buffer integrity after download, transfer, or decompression
• Computing checksums inside ZIP/OOXML format handling (the library’s original use case in SheetJS’s spreadsheet parsers)
• Generating fast, non-cryptographic cache keys or dedup fingerprints for byte content
• Command-line checksum verification via the bundled crc32 CLI script
• Cross-checking output against Python’s zlib.crc32 or Unix cksum for interoperability testing

Under The Hood

Architecture crc-32 is a tightly self-contained UMD module (crc32.js) with a mirrored CRC32C variant (crc32c.js) and matching ESM builds — there is no framework, dependency injection, or multi-layer structure because the entire surface area is a lookup-table CRC computation. The core algorithm precomputes a 256-entry signed CRC table (signed_crc_table) and then unrolls it into sixteen slice tables (T0 through Tf) via slice_by_16_tables, letting crc32_buf process sixteen bytes per loop iteration by XOR-combining sixteen simultaneous table lookups instead of one byte at a time; crc32_str and crc32_bstr fall back to a byte-at-a-time loop with inline UTF-8 encoding for JS string input. Because every function is a pure computation over its input with no shared mutable state beyond the precomputed tables, the only thing that would break if the core abstraction changed is the table-generation step itself — the public API (buf/bstr/str) would be untouched by any internal optimization.

Tech Stack The published package has zero runtime dependencies; it targets plain JavaScript (with an Int32Array fast path, falling back to a plain Array on ancient engines). Development tooling is unusually old-school for its ecosystem: builds and tests run through a Makefile rather than a bundler, mocha drives the test suite with blanket for coverage, and @sheetjs/uglify-js produces the minified browser build. Type-safety is provided via a hand-authored types/index.d.ts checked by dtslint against a small crc32-test.ts fixture. The package.json exports map serves crc32.mjs for import and crc32.js for require, and a bin/crc32.njs Node script plus a reference bin/crc32.py implementation are shipped alongside the library for CLI use and cross-language verification.

Code Quality Test coverage is more extensive than the library’s size would suggest: test.js runs table-value checks, bit-level correctness tests across a fixture corpus (misc/bits.js), Unicode category baselines per charset, and full-corpus buffer hashing, exercising bstr/str/buf parity and rolling-CRC (seeded) computation over chunked substrings. Error handling is minimal by design — the checksum functions have no failure modes to handle since they operate on data already in memory, though the CLI wrapper does include explicit file-read error handling. Linting is configured through legacy, overlapping tools (.eslintrc, .jshintrc, .jscs.json) and CI runs on Travis CI, a service that has been effectively defunct for years, which combined with the project’s last commit in 2022 suggests the maintenance process itself is aging even though the code and tests remain correct.

API Design The public API is about as low-friction as a checksum library can be: three verbs (buf, bstr, str) with an identical calling convention, and a CRC32C variant reachable by importing a different subpath rather than passing a flag. There’s no setup, configuration object, or class instantiation — you call the function on your data and get an integer back. The one deliberate wrinkle is that results are signed 32-bit integers rather than the unsigned values most CRC32 tooling emits by default, which is well-documented in the README with explicit >>> 0 and | 0 conversion recipes, but is still a common first-use surprise for anyone porting checksums from another language or tool.