CRC校验和计算器

What is a CRC checksum?

A Cyclic Redundancy Check (CRC) is a short, fixed-size value calculated from a block of data and used to detect accidental changes — corruption introduced by a noisy transmission line, a scratched disk sector, or a truncated file transfer. Feed the same data into the same CRC algorithm twice and you always get the same checksum; change even a single bit and the checksum almost always changes too, which is what makes CRCs useful for catching errors quickly and cheaply.

CRCs are everywhere in computing infrastructure: CRC-32 verifies every file stored in a ZIP archive and every chunk inside a PNG image, and it runs in hardware on every Ethernet frame to catch bit errors introduced by the wire. CRC-16 variants show up in serial protocols, Modbus, XMODEM file transfer, and countless embedded systems where a lightweight 16-bit check is enough.

CRC is not a cryptographic hash

This is the most important thing to understand about CRC: it is not designed to resist tampering. A cryptographic hash like SHA-256 is built so that finding two different inputs with the same output (a "collision") is computationally infeasible. CRC offers no such guarantee — it's a linear function, and constructing a second input that produces an identical CRC is often trivial once you know the algorithm. That trade-off is intentional: CRC is optimized for speed and for catching random errors, not for resisting a deliberate adversary. Never use CRC-32 or CRC-16 to verify a file hasn't been maliciously tampered with, to store a password, or anywhere else you need real security guarantees — reach for a SHA-2/SHA-3 hash generator instead.

How to use this tool

1. Paste or type the text you want to check into the Input Text box.
2. Choose an algorithm — CRC-32 (the default, used by ZIP/PNG/Ethernet) or CRC-16/CCITT-FALSE.
3. The checksum updates automatically, shown as an uppercase hexadecimal value prefixed with 0x.

Everything runs client-side in your browser — nothing you paste in is ever uploaded.

FAQ

Why does my checksum differ from another tool's output? CRC is a family of algorithms that share the same basic table-driven technique but differ in their polynomial, initial register value, bit order (reflection), and final XOR. "CRC-32" and "CRC-16/CCITT-FALSE" are specific, standardized parameter sets — if another tool uses a different CRC-16 variant (XMODEM, MODBUS, IBM/ARC, USB), you'll get a different number for identical input, even though both are valid CRC-16 checksums.

What's the standard test to confirm an implementation is correct? The universally cited reference vector is the ASCII string 123456789. A correct CRC-32 implementation returns 0xCBF43926 for that input; a correct CRC-16/CCITT-FALSE implementation returns 0x29B1. Any conforming CRC library, in any language, reproduces these exact values.

Can I verify a file's integrity with this tool? Yes for accidental corruption — paste the file's text content and compare the checksum against a known-good value (e.g., from a ZIP archive's stored CRC-32). It is not suitable for verifying a file hasn't been intentionally altered.

Does whitespace or encoding affect the result? Yes — CRC operates on raw bytes, so trailing whitespace, line-ending differences (\n vs \r\n), and text encoding all change the checksum, even if the visible text looks identical.

Privacy

This tool runs entirely in your browser. Your input text is never sent to a server.