CRC-32 checksum

This CRC-32 checksum tool accepts plain text, serializes it as UTF-8, and runs the standard IEEE profile used by PKZIP, PNG, and ISO-HDLC—the same path that yields the famous check value cbf43926 for the ASCII string one-two-three-four-five-six-seven-eight-nine.

What CRC-32 means and which polynomial this tool uses

A cyclic redundancy check treats your message as a binary polynomial and divides it by a fixed generator polynomial, keeping a short remainder that is highly sensitive to changes in the original bits. For CRC-32 the remainder is thirty-two bits wide, usually shown as eight hexadecimal digits. This capability implements the reflected IEEE polynomial often written as zero-x-E-D-B-eight-eight-three-two-zero in software, with initial value all ones and a final exclusive-or of all ones. That exact parameter set is the ZIP and PNG CRC, also catalogued as CRC-32 slash ISO-HDLC or CRC-32 slash PKZIP in reverse-engineering tables. It is not Castagnoli CRC-32C used by some storage systems, not the MPEG-2 non-reflected variant, and not a cryptographic hash: CRC-32 is designed for fast integrity checks against accidental corruption, not for resisting deliberate forgery. Input text is first encoded as UTF-8 so multi-byte characters such as accented letters or emoji contribute their real on-the-wire bytes, matching how most file formats and HTTP bodies treat strings. The well-known validation vector is the nine-digit ASCII payload one through nine, which must produce hexadecimal c-b-f-four-three-nine-two-six; empty input must produce eight zeros. If a third-party tool disagrees with this endpoint on the same UTF-8 bytes, it is almost always using a different polynomial, a different init or xor-out, or hashing a different encoding of the same characters.

Input contract, response fields, and empty input behaviour

Empty string is allowed on purpose: many CRC libraries document the zero-length residual as zero, and pipelines that hash optional fields need a stable answer instead of a hard failure. Algorithm is always the label CRC-32 slash ISO-HDLC and polynomial is always the string zero-x-E-D-B-eight-eight-three-two-zero so OpenAPI examples and support replies can quote the profile without ambiguity. There is no mode switch for other CRC widths or polynomials: if you need CRC-16, Adler-32, or a cryptographic digest, use a dedicated capability so each landing page matches a single search intent. POST a JSON body with the required field text set to the string you want to checksum. Aliases input, value, s, string, and content are accepted so older forms and short clients still bind. Finite numbers and big integers are stringified; objects, arrays, booleans, null, Infinity, and NaN raise invalid_input and are not billed. When the source length is zero the response sets empty to true, crc32 to eight zero digits, crc32_int to zero, and bytes to zero. For non-empty input empty is false, bytes equals the UTF-8 length (which can exceed the JavaScript character length for multi-byte glyphs), crc32 is the lowercase eight-digit hex residual without a zero-x prefix, and crc32_int is the same value as an unsigned thirty-two-bit integer useful in languages that prefer numbers over strings.

Where a CRC-32 checksum API earns its keep

Developers paste short configuration fragments, protocol samples, and filename stems into a CRC-32 checksum calculator when they need a compact integrity tag that matches ZIP and PNG tooling without installing a local utility. Support engineers recompute residuals from ticket text to confirm that a pasted dump was not truncated in transit. Education labs use the same endpoint to show that changing one character flips many hex digits, illustrating error detection without introducing cryptographic machinery. Keep payloads under the documented character ceiling, treat the hex field as the canonical paste target, and you get reproducible ZIP-compatible CRC-32 values for docs, SDKs, edge workers, and classroom demos without standing up a separate hash service.