CRC-32
Compute CRC-32 (IEEE) locally over UTF-8 text
Text input produces checksums in two number formats. Input is UTF-8 text: typing 41 does not automatically mean a hexadecimal byte.
| Hex | ||
|---|---|---|
| Decimal |
Example
Input
123456789
Example result
Hex: cbf43926 Unsigned decimal: 3421780262
This common CRC check input has no trailing newline.
Technical details & limits
The reflected polynomial is 0xEDB88320, with initial value and final XOR of 0xFFFFFFFF, matching common CRC-32/ISO-HDLC. CRC-32C and other variants use different parameters. Text is encoded as UTF-8 before calculation; a final newline changes the checksum.
About this tool
Compute the CRC-32 checksum of UTF-8 text in hexadecimal and unsigned decimal. Check accidental corruption and implementation behavior; CRC does not authenticate data against deliberate tampering.
Use cases
- Quickly check whether a chunk of text matches a previous version.
- Use as a lightweight hash key (e.g. cache sharding).
How to use
- Paste text into the input.
- Decimal and hexadecimal values update live.
Notes
CRC-32 is not a cryptographic hash — do not use it for tamper detection.
FAQ
- What CRC32 value does the text 123456789 produce?
- This tool's CRC-32/ISO-HDLC calculation returns CBF43926 for the text 123456789. It uses a 32-bit checksum and the reflected polynomial 0xEDB88320. Input is encoded as UTF-8 before calculation, so an extra space or trailing newline changes the bytes involved. Keep the sample exact when comparing implementations, and confirm the variant parameters rather than assuming that every algorithm labeled CRC32 should produce the same output.
- Are CRC32 and CRC-32C checksums interchangeable?
- CRC32 and CRC-32C use different parameters, so their results are not interchangeable. This tool uses polynomial 0xEDB88320, with both the initial value and final XOR set to 0xFFFFFFFF. Compare the complete variant definition when checking a protocol or device result. A name containing 32 only indicates the checksum width and is insufficient to establish identical polynomial, reflection, initialization, and final-processing rules across implementations.
- Why does CRC32 of the text 41 differ from CRC32 of A?
- This tool treats 41 as text rather than as hexadecimal byte notation. The text 41 contains 2 ASCII bytes, while A contains 1 byte whose hexadecimal value is 0x41. The checksum therefore receives different inputs. Before comparing results, confirm that both programs process the same encoded bytes, including any spaces or line endings, instead of assuming that a textual number is automatically interpreted as a byte value.
Related tools
Text hash (MD5 / SHA)
Base64 encode / decode