Hex CRC-32 Calculator
Hex CRC-32 Calculator. Paste your bytes into Hex Byte Input and the Hex CRC-32 Calculator instantly returns your CRC-32 Checksum (Hex). If a value only exists in Base64 form, the base64 to hex converter converts it back to hex so you can inspect the raw bytes.
Paste text or hex bytes into the hex CRC-32 calculator and you get the CRC32 checksum of that data in hexadecimal and unsigned decimal, instantly and inside your browser. It applies the same IEEE 802.3 polynomial that ZIP, PNG and Ethernet rely on, so the answer you read here is the one those formats would store or send.
How a CRC-32 Checksum Calculator Works
A CRC-32 checksum calculator reads your input one byte at a time and folds each byte into a running 32-bit register. When the last byte is consumed, the register is flipped once more and printed as eight hex digits. The output is a fixed 8-character string whether you feed in a single letter or a whole file, which is why the routine is sometimes borrowed as a hash function even though it was never designed to be one. When working with legacy IBM mainframe output, the ebcdic to text converter converts the raw EBCDIC hex bytes into a readable string.
You choose how the input is read: plain text, a hex string such as 54 65 6C, or Base64. Text is turned into bytes with UTF-8, which matches ASCII for ordinary English characters, while a hex string is taken byte for byte after spaces and any 0x prefix are removed. The tool then reports the CRC value twice, so you can paste whichever form your specification asks for.
Cyclic Redundancy Check Basics and Data Corruption
A cyclic redundancy check is an error-detecting code. The sender computes a short check value from the data and transmits it alongside, and the receiver recomputes it and compares the two. When they match, your digital data arrived intact; when they differ, something changed on the way, so you can detect the problem before trusting the payload. Causes include electrical noise during data transmission over a network link, a failing hard-disk sector or a worn memory card, and each one shows up as data corruption that a CRC is built to catch.
Compared with a simple additive checksum, a CRC is far better at helping you detect errors that arrive in bursts, because it treats the whole message as one long binary number and keeps the remainder after division by a fixed divisor. A one-byte sum has only 256 values and cannot see two flipped bits that cancel out, while a 32-bit CRC leaves roughly one chance in 4.29 billion that accidental changes slip through. That is why serial data links and embedded systems moved beyond a lone parity bit, and why dedicated hardware in network communications computes a CRC for every one of the packets it handles.
CRC-32 Formula and the Generator Polynomial
The calculation is polynomial division over binary numbers, where subtraction is just XOR and nothing carries. Your message is shifted left by 32 places, divided by the generator polynomial, and the 32-bit remainder becomes the answer after a final inversion:
$$\text{CRC}(M) = \big(M(x) \times x^{32} \bmod G(x)\big) \oplus \text{0xFFFFFFFF}$$For CRC-32 the divisor is the IEEE 802.3 polynomial:
$$G(x) = x^{32} + x^{26} + x^{23} + x^{22} + x^{16} + x^{12} + x^{11} + x^{10} + x^{8} + x^{7} + x^{5} + x^{4} + x^{2} + x + 1$$Written as hex it is 0x04C11DB7, and its bit-reversed form 0xEDB88320 is the constant most software uses because it processes the least significant bit of each byte first. Both describe the same CRC-32 checksum.
Worked Example: CRC Calculation for Telemetry-0417
Take the 14-character label Telemetry-0417, the kind of identifier a logging device might stamp on a record. The table shows what the calculator does with it.
| Quantity | Value |
|---|---|
| Input text | Telemetry-0417 |
| Bytes as hex | 54 65 6C 65 6D 65 74 72 79 2D 30 34 31 37 |
| Length | 14 bytes |
| CRC-32 in hexadecimal | 29CEFA50 |
| CRC-32 in unsigned decimal | 701,430,352 |
| Little-endian byte order | 50 FA CE 29 |
Change one or two characters and the output moves completely, which is what makes the code useful for catching mistakes:
| Input text | CRC-32 (hex) | What changed |
|---|---|---|
| Telemetry-0417 | 29CEFA50 | Original |
| Telemetry-0416 | 5EC9CAC6 | Last digit off by one |
| Telemetry-0471 | 96F7F8E3 | Last two digits swapped |
Using the Hex CRC-32 Calculator: Input and Output Formats
Entering the Input String
Type or paste your input string into the box and press the button. Choose hex when you already hold raw bytes, for example a frame captured from a device, and leave out the 0x prefix. A single stray space or trailing newline changes the bytes, and therefore the answer, so copy only the characters you mean to include.
Reading Hexadecimal and Unsigned Decimal Output
The hexadecimal line is the usual way to quote a CRC-32, always padded to eight digits, so a leading zero is never dropped. The unsigned decimal line is the same 32-bit number read as a plain integer between 0 and 4,294,967,295. Some tools print little-endian byte order instead, as in the table above; the digits are identical, only the byte order differs. The hex CRC-32 calculator shows both so you can match whichever convention your protocol uses.
Checking a Device Record with the Hex CRC-32 Checksum Calculator
A field technician is provisioning a data logger and the device reports a configuration record ending in the CRC-32 F818F831. Before signing off the unit, she wants to know whether the record that was flashed is the one in the work order, so she runs a CRC calculation of her own instead of comparing the text by eye.
The work order lists the record as SN=K41907;FW=3.8.2, 18 characters including the semicolon. She pastes exactly that into the text box with no trailing newline, keeps the standard IEEE 802.3 settings, and presses the button. The calculator returns F818F831 in hexadecimal and 4,162,385,969 in unsigned decimal. Both match what the logger printed, which tells her the stored bytes are identical to the work order, character for character.
She does not stop there. A firmware tag is the easiest thing to mistype, so she reruns the check with one change, swapping the last two digits of the version to FW=3.2.8. The checksum jumps to 155A94F9, nothing like the first, so a transposed version number could never pass for the correct one. The result also lines up with the 8-hex-digit width she expects from a 32-bit code, so she knows the tool is not truncating the value.
Her last step is the decision the number allows: because the CRC value agrees with the work order, she marks the record as verified and moves to the next unit. Had it differed, her next action would be to re-read the record from the device and compare the raw hex bytes to find which one changed, since a CRC mismatch says that something differs but not what.
CRC Calculation Online: Algorithm Parameters Explained
Two tools can both claim to compute "CRC-32" and still disagree, because the final value depends on a handful of settings. When you run a CRC calculation online and the number does not match your device, one of these parameters is nearly always the cause.
| Parameter | Meaning | Standard CRC-32 |
|---|---|---|
| Bit width | Length of the result | 32 |
| Polynomial | Divisor, highest term omitted | 0x04C11DB7 |
| Initial value | Starting register contents | 0xFFFFFFFF |
| REFIN | Reverse the bits of each input byte | true |
| REFOUT | Reverse the bits of the final result | true |
| XOROUT | Value XORed with the result | 0xFFFFFFFF |
| Check, input 123456789 | Published test vector | CBF43926 |
Bit Width, Initial Value and XOROUT
The bit width sets how many hex digits come back, here eight. The initial value preloads the register with all ones, which stops leading zero bytes from being ignored, and XOROUT inverts the finished register. Skip either step and you get a different, equally valid, but incompatible answer.
REFIN, REFOUT and the Custom Algorithm Option
REFIN and REFOUT control bit order. Standard CRC-32 reverses both, which is why the reflected constant appears in code. If you need a protocol that sets them differently, use the custom algorithm option and enter the six values yourself; the test input 123456789 is the quickest way to confirm a setup, because each published model lists its own check value for it.
CRC32 Checksum Generator in Code: The Table-Based Implementation
Software that works as a CRC32 checksum generator usually avoids dividing bit by bit. The table-based implementation precomputes a lookup of 256 entries, one for every possible byte, so each input byte costs one table read and one XOR. The first entries, built from the reflected constant, are 00000000, 77073096 and, for the last one, 2D02EF8D.
uint32_t crc = 0xFFFFFFFF;
for (size_t i = 0; i < n; i++)
crc = table[(crc ^ data[i]) & 0xFF] ^ (crc >> 8);
return crc ^ 0xFFFFFFFF;This short loop is a complete C implementation once the table exists. If you want ready-made source code, a maintained library such as zlib already exposes the same routine, and its output matches this page for the standard parameters.
CRC Calculator Choices: CRC-8, CRC-16, CRC-32 and CRC-64
A CRC calculator family covers several widths, and the number in the name is the polynomial's degree. Longer codes catch more error patterns at the price of a longer check value.
- CRC-8: one byte, common on small sensors and short messages.
- CRC-16: two bytes, with variants such as CCITT and Modbus that differ only in their parameters.
- CRC-32: four bytes, the general-purpose choice for files and network frames.
- CRC-64: eight bytes, used where very large data sets need extra margin.
Where a CRC Value Shows Up in File Formats and Storage
You meet this value more often than you may realise. Most file formats that care about integrity store one:
- ZIP archives keep a CRC-32 for every entry, so an extractor can confirm each file after unpacking.
- gzip finishes every compressed stream with one.
- PNG images attach one to every chunk.
- Ethernet frames end with a frame check sequence built on the same polynomial.
Because a computer can recompute it in a fraction of a second, it is a cheap way to confirm that a download or a copy to new storage matches the original.
Limits of a CRC32 Checksum Calculator: Not a Cryptographic Hash
A CRC catches accidents, not attacks. It is not a cryptographic hash, and anyone can craft a different message with the same code, so a collision is trivial to produce on purpose. Never use it for security, tampering checks or password storage; reach for a proper hash generator based on SHA-256 for those jobs. Treat the result as a quick check for transmission faults and nothing more, and remember that two different checksums for one input usually means a parameter mismatch rather than a broken tool.