The most common CRC-32 implementation, also called CRC-32b. It uses the reflected form of polynomial 0x04C11DB7, namely 0xEDB88320. Both input bytes and output are bit-reflected (LSB first), with initial value and final XOR both set to 0xFFFFFFFF.

Widely used by ZIP, gzip, PNG images, Ethernet frames (IEEE 802.3), PKCS#7, and many legacy systems. This is the de facto "default CRC-32" variant.

Proposed by G. Castagnoli and colleagues in 1993, this variant uses polynomial 0x1EDC6F41 (reflected form 0x82F63B78). At the same Hamming distance, it offers stronger burst-error detection than the ISO-HDLC polynomial.

Hardware acceleration is available through Intel SSE4.2 and ARM CRC32 instructions. It is widely used in modern storage and transport protocols such as iSCSI, NVMe, Btrfs, and SCTP.

Uses the same 0x04C11DB7 polynomial as ISO-HDLC, but neither input nor output is bit-reflected (MSB first, big-endian). The initial value is 0xFFFFFFFF and the final XOR is disabled (XorOut = 0x00000000).

Mainly used for PSI/SI tables in MPEG-2 transport streams (PAT, PMT, NIT, and related tables), plus integrity checks in DVB and ATSC broadcast systems.

Its parameters are almost identical to MPEG-2 (polynomial 0x04C11DB7, no reflection, initial value 0xFFFFFFFF). The only difference is a final XOR with 0xFFFFFFFF, which flips every bit. It is also known as CRC-32/AAL5 or CRC-32/DECT-B.

Used by the BZip2 compressed file format and the trailer checksum field of the ATM AAL5 protocol.

Treats the input as a UTF-8 string, converts it to bytes, and then calculates CRC32. This is the most common mode for plain text, source code, JSON, and similar content.

Note: the same text encoded with a different character set such as GBK or UTF-16 produces a different byte stream and therefore a different CRC32 value. This tool always uses UTF-8.

Treats the input as raw hexadecimal byte literals. Spaces and line breaks are ignored. Every two hex characters become one byte (00–FF).

Useful when you need CRC checks for exact binary data such as network frames, firmware image fragments, or memory dumps. You can paste Wireshark or hex dump output directly.

Treats the input as a Base64-encoded string, decodes it into raw bytes, and then calculates CRC32. Useful for PEM certificates, JWT payloads, Data URIs, and other Base64 content.

Supports the standard Base64 alphabet (A-Z a-z 0-9 + /). The padding character = is optional. URL-safe Base64 (- _) is not supported.

Displays the value as an 8-digit uppercase hexadecimal number prefixed with 0x. Each character represents 4 bits, for a total of 32 bits. This is the standard format used in most tools, source code, and documentation.

Compared with decimal output, hexadecimal makes byte boundaries easier to inspect and matches memory dumps and protocol fields more naturally.

Displays the checksum as an unsigned 32-bit decimal integer in the range 0–4,294,967,295 (2³²−1). Some languages and tools compare CRC values in decimal form, and database fields often store this representation.

Note: CRC32 results should be treated as unsigned integers. In signed int types such as Java or C#, values above 0x7FFFFFFF may appear negative and should be converted to uint or a wider unsigned representation.

Displays the checksum as a 32-bit binary string prefixed with 0b. Each character is 0 or 1, aligned with the most significant bit on the left, and padded with leading zeroes when necessary.

Mainly useful for understanding the internal CRC algorithm, studying polynomial division, teaching, and embedded scenarios that need bit-level checksum processing.

Displays the checksum as an 11-digit octal number prefixed with 0o. At most 11 octal characters are needed for 32 bits because 3×11 = 33 > 32. Each octal digit represents 3 bits.

Octal output is uncommon in modern CRC workflows, but it still appears in some Unix tools, embedded firmware toolchains, and older communication protocol specifications.