Why does my digest not match the one on a download page?

Almost always because the bytes differ, not because either calculator is wrong. A trailing newline, a different line-ending style (CRLF vs LF), or pasting text instead of hashing the actual file all produce a completely different digest, since a hash is computed over exact bytes.

Which algorithm should I use?

SHA-256 for anything where the result needs to be trustworthy against tampering. CRC-32 or Adler-32 for detecting accidental corruption in a protocol or file format that expects one of those specifically. None of the three non-cryptographic ones (CRC-32, Adler-32, FNV-1a) should be relied on where someone might deliberately try to produce a matching digest.

Checksum and Hash Calculator

A hash is only useful if it is the standard one. A digest that is self-consistent but does not match what everybody else computes is worse than none at all, because it will disagree with the file you are checking against. Getting the same answer twice proves nothing; getting the answer the rest of the world gets proves the point, so that is what is checked here.

Your text

Up to 200,000 characters.

Algorithm

Your digest will appear here.

What this generator does

Turns your text into UTF-8 bytes and works out the digest, then reports how much of that digest changes if a single input bit does.

How to use this tool

Paste the text you want a digest of.
Choose the algorithm.
Copy the digest.
Note how much of it changes when you alter a single character.

Understanding the controls

Your text: Up to two hundred thousand characters. The digest is taken over the bytes, so accents and emoji count for more than one character each.
Algorithm: SHA-256 for anything that needs to be trustworthy, CRC-32 and Adler-32 for detecting damage, FNV-1a for a fast non-secure hash.

Worked examples

SHA-256 of an empty string: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 — the standard published value for zero input bytes, a common way to sanity-check any SHA-256 implementation.

Common use cases

Checking a SHA-256 digest quoted alongside a download
Working out the CRC-32 of a string for a protocol or a format
Comparing two pieces of text by their digests
Seeing how a cryptographic hash scatters a small change
Producing a stable identifier from a piece of text

How this generator works

Each algorithm is run against its published test vectors — the CRC-32 check value of 0xCBF43926, the SHA-256 worked examples from the specification, the Adler-32 example from the zlib documentation — and must match to the last character. A one-bit change is also made to the input and the digests compared, which shows SHA-256, CRC-32 and FNV-1a each scattering a small change across a large share of their bits, while Adler-32, which is little more than a running sum, barely moves.

Randomness and fairness

Nothing is random. The same text always gives the same digest, on any device.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

Text only. Hashing a file needs the file itself, which this does not take.
SHA-256 is the only cryptographic hash offered; MD5 and SHA-1 are broken for anything security-related and are left out.
CRC-32, Adler-32 and FNV-1a detect accidental damage and are trivially forged, so none of them is a security check.
The digest is of the exact bytes given, so an extra newline changes it completely — which is usually the reason two digests disagree.

Privacy and your data

Digests are computed in your browser. Nothing you paste is transmitted or stored.

Frequently asked questions

Why does my digest not match the one on a download page?: Almost always because the bytes differ, not because either calculator is wrong. A trailing newline, a different line-ending style (CRLF vs LF), or pasting text instead of hashing the actual file all produce a completely different digest, since a hash is computed over exact bytes.
Which algorithm should I use?: SHA-256 for anything where the result needs to be trustworthy against tampering. CRC-32 or Adler-32 for detecting accidental corruption in a protocol or file format that expects one of those specifically. None of the three non-cryptographic ones (CRC-32, Adler-32, FNV-1a) should be relied on where someone might deliberately try to produce a matching digest.