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
- Does it match Linux `crc32`?
- Yes (same IEEE polynomial). Discrepancies usually come from encoding or line-ending differences.
- Does matching CRC prove two files are identical?
- No. The 32-bit result can collide and CRC is not cryptographically resistant to manipulation. Use an appropriate digest and trusted reference for stronger integrity checks.
- Why is CRC-32C different?
- CRC-32C uses another polynomial. Match the polynomial, initial value, reflection and final XOR when comparing results.
- Why do the inputs 41 and A have different checksums?
- There is no raw-hex input mode. The string 41 is encoded as two text characters, while A is one character whose byte is hex 41. The processed bytes differ.
Related tools
Text hash (MD5 / SHA)