Security Runs locally Ready to use Built-in examples No tracking

CRC-32 Checksum Calculator

Paste any text to get its CRC-32 value in hex and decimal. It is the same algorithm used inside zip, gzip and PNG, so it is the quick way to check whether data was damaged in transit.

CRC-32 is the checksum that catches damage in transit: zip, gzip and PNG all use it internally (the IEEE 802.3 variant). Paste the text and an 8-digit hexadecimal value comes back, with the uppercase and decimal forms alongside — three ways of writing the same number, so take whichever format the other side gave you.

Its position needs to be clear: CRC-32 needs no key and computes in an instant, but it is only 32 bits, and an attacker can construct different content carrying the same checksum, so it answers whether the data was damaged on the way, not whether someone tampered with it deliberately. Tamper detection wants SHA-256 or a signed checksum. When values disagree, check line endings first — CRLF and LF are different bytes — and then the encoding.

—

—

How to use

  1. Paste the text.
  2. Read the hexadecimal, uppercase and decimal forms.
  3. Compare using the same format the other side published.
  4. Check line endings and encoding if the values differ.

How it works

Basic usage

Paste content into the box and the result updates instantly: the main result is 8 lowercase hex characters, with uppercase and the decimal value on the lines below. All three are the same number in different notations — match whichever format the other side gave you.

What CRC-32 actually computes

CRC-32 treats the whole data as one long binary polynomial, divides it and keeps the remainder as the checksum: flip a single bit anywhere and the remainder almost certainly changes. It needs no key and computes blazingly fast, which is why zip, gzip and PNG — formats built to catch transmission damage quickly — all use it.

What it cannot prove

It cannot stop deliberate tampering: an attacker can craft content whose CRC-32 matches the original (a collision), so it never proves a file is "unmodified". Tamper resistance needs a collision-resistant digest like SHA-256, or a signed verification.

Method: IEEE 802.3 CRC-32 (the same variant used by zlib, zip, gzip and PNG), reflected polynomial 0xEDB88320 with 0xFFFFFFFF as both the initial value and the final XOR. The input is encoded as UTF-8 and processed byte by byte; output is 8 lowercase hex digits.

Code example

Python The standard library's zlib 

import zlib

zlib.crc32(b"hello")                  # 907060870
format(zlib.crc32(b"hello"), "08x")   # "3610a686"

# Same rule as zip / gzip / PNG (IEEE 802.3)

JavaScript Built in from Node 20 onwards 

const { crc32 } = require("node:zlib");

crc32(Buffer.from("hello")).toString(16).padStart(8, "0");
// "3610a686"

// On older Node, use a third-party crc library, or cross-check with a zip tool

FAQ

CRC32 vs. MD5 checksums — how do they differ?

CRC32 is 32 bits (8 hex digits) and extremely fast, designed to catch random transmission noise; MD5 is 128 bits with far stronger collision resistance (though collisions can now be constructed). For "did my download corrupt?" use CRC32; for "was the content replaced?" use SHA-256.

Why does my local CRC32 differ from this one for the same file?

Confirm three things match: content scope (this tool hashes the entire input box content as UTF-8 — check for stray newlines or spaces), line endings (Windows CRLF vs. Linux LF are different bytes), and encoding (Chinese text must be UTF-8 on both sides).

Is the CRC32 result 8 or 10 digits?

Hexadecimal is 8 digits (e.g. cbf43926); the corresponding decimal is up to 10 digits (e.g. 3421780262). Two notations of the same 32-bit number, no precision difference — if the other side gave decimal, compare against the decimal line in the result.

Can CRC32 detect malicious modification?

No. CRC-32 is not a cryptographic digest: crafting two contents with equal CRC32 is feasible, and a normal file's CRC32 is public anyway. It answers "did the data get damaged in transit?", not "did someone swap the content?" — for the latter use SHA-256.

What encoding does CRC32 use for Chinese text?

This tool encodes everything as UTF-8 before computing. The same character has different bytes in GBK and UTF-8, hence different checksums — confirm both sides use UTF-8 before comparing with a server or archive, or identical-looking text will mismatch.

Why does empty content have a checksum?

CRC-32 is well defined for empty data: 00000000 (decimal 0). The register is initialized, zero bytes are processed, and the final XOR with the mask yields exactly 0. An empty input isn't "not computed" — it's a legitimate result.

Are CRC32, CRC32C and Adler-32 the same algorithm?

No. CRC32C (Castagnoli) uses a different polynomial and appears in iSCSI, SSE4.2 instructions and some filesystems; Adler-32 is zlib's even faster, weaker checksum. Their values never match — confirm which one the other side used. This tool implements the most common IEEE 802.3 variant.

Does this page upload my content?

No. Computation happens entirely inside the browser; the input never reaches a server and never enters access logs. There's no history section, so pasting internal data leaves no trace either.