The most common CRC-32 implementation, also called CRC-32b. It uses di reflected form of polynomial 0x04C11DB7, namely 0xEDB88320. Both input bytes and output na 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. Dis na di de facto "default CRC-32" variant.

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

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

Uses di same 0x04C11DB7 polynomial as ISO-HDLC, but neither input nor output nabit-reflected(MSB first, big-endian). Di initial value na 0xFFFFFFFF and di final XOR na 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 na almost identical to MPEG-2 (polynomial 0x04C11DB7, no reflection, initial value 0xFFFFFFFF). Di only difference na afinal XOR with 0xFFFFFFFF, which flips every bit. It na also known as CRC-32/AAL5 or CRC-32/DECT-B.

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

Treats di input as aUTF-8string, converts it to bytes, and then calculates CRC32. Dis na di most common mode for plain text, source code, JSON, and similar content.

Note: di 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. Dis tool always uses UTF-8.

Treats di input as rawhexadecimal byte literals. Spaces and line breaks na 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 fit paste Wireshark or hex dump output directly.

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

E support di standard Base64 alphabet (A-Z a-z 0-9 + /). Di padding character=na optional. URL-safe Base64 (-_) na not supported.

E show di value as an 8-digit uppercase hexadecimal number prefixed with0x. Each character represents 4 bits, for a total of 32 bits. Dis na di 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.

E show di checksum as anunsigned 32-bit decimal integerin di range 0–4,294,967,295 (2³²−1). Some languages and tools compare CRC values in decimal form, and database fields often store dis representation.

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

E show di checksum as a 32-bit binary string prefixed with0b. Each character na 0 or 1, aligned with di most significant bit on di left, and padded with leading zeroes when necessary.

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

E show di checksum as an 11-digit octal number prefixed with0o. At most 11 octal characters na needed for 32 bits because 3×11 = 33 > 32. Each octal digit represents 3 bits.

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