CRC Checksum Calculator

CRC Checksum Calculator

Computes CRC from UTF-8 encoded text in a textarea, with algorithm choices CRC32 (default), CRC16 and CRC8. Hello is placeholder text, not prefilled data. It does not parse hexadecimal byte strings: input 41 hashes two text characters, not the single byte represented by hex 41. No file upload or input-encoding selector exists.

CRC32 uses a reflected right-shift polynomial 0xEDB88320, initial 0xFFFFFFFF and final XOR 0xFFFFFFFF. CRC16 uses reflected polynomial 0xA001, initial 0xFFFF and no final XOR; the selector states the polynomial and initial value instead of an ambiguous IBM label. CRC8 uses polynomial 0x07, initial 0 and no final XOR, processing most-significant bits. Do not assume that every CRC16 or CRC8 variant uses these parameters.

Verified input 123456789 produces CRC32 CBF43926, CRC16 4B37, CRC8 F4. Empty text produces 00000000, FFFF, 00 respectively. Output is uppercase hexadecimal padded to 8, 4 or 2 characters with an algorithm label, not raw transmitted bytes or a byte-order selector.

TextEncoder encodes the literal text as UTF-8; spaces, case and line breaks affect the checksum. Hello and Hello followed by a newline differ. No Unicode normalization, trimming or locale-number parsing is performed. Localized dates or decimal strings are just different byte sequences, not equivalent numeric values.

Input is limited to 500000 JavaScript UTF-16 code units by the shared guard; UTF-8 byte length can be larger. Calculation runs locally on the page thread; mobile users should begin with small text and use the calculation action after edits. Clear resets text/result. No expected-value comparison or automatic pass/fail validation exists.

CRC detects many accidental transmission changes but is not encryption, a digital signature, collision-resistant authentication or a password hash. To compare with another system match the complete algorithm parameters and exactly the same bytes, including encoding/newlines. No input is uploaded or sent to AI.