SHA-256 maps these 43 bytes to a 256-bit digest. Flipping a single input bit changed 141 of the 256 digest bits (55.1%), so near-identical inputs get unrelated digests.
Avalanche test, SHA-256 (first 64 of 256 bits)
Digest of the input
1
1
0
1
0
1
1
1
1
0
1
0
1
0
0
0
1
1
1
1
1
0
1
1
1
0
1
1
0
0
1
1
0
0
0
0
0
1
1
1
1
1
0
1
0
1
1
1
1
0
0
0
0
0
0
0
1
0
0
1
0
1
0
0
Digest with bit 0 of byte 1 flipped
1
0
0
0
1
0
1
0
1
1
0
0
1
1
1
0
0
0
1
0
1
1
0
1
0
0
1
1
1
0
0
1
0
0
0
1
0
1
1
0
0
1
1
0
0
0
0
1
0
0
0
0
0
1
1
1
0
1
1
0
1
1
1
1
Bits that differ
0
1
0
1
1
1
0
1
0
1
1
0
0
1
1
0
1
1
0
1
0
1
1
0
1
0
0
0
1
0
1
0
0
0
0
1
0
0
0
1
1
0
1
1
0
1
1
0
1
0
0
0
0
1
1
1
1
1
1
1
1
0
1
1
Share of digest bits changed by a one-bit input change
How it's calculated S
Encode the text as UTF-8
Characters: 43 → bytes: 43 (344 bits).
Pad to whole blocks
blocks=⌊64n+8⌋+1=⌊6443+8⌋+1=1
Append a 1 bit, zeros, and the 64-bit message length so the padded message is a multiple of 512 bits.
Run the compression function
1block×64rounds=64rounds
Each block updates a state of eight 32-bit words, which is added back into the running state after the block.
A cryptographic hash turns any input into a fixed-size digest: 128 bits for MD5, 160 for SHA-1, 256 for SHA-256 and 512 for SHA-512, while CRC-32 is a 32-bit error-detecting checksum. The text is encoded as UTF-8, padded to whole 512-bit or 1024-bit blocks, and run through the algorithm's compression rounds as NIST FIPS 180-4 and RFC 1321 specify.
People use it to verify downloads against a published checksum, compare files and test their own code. The default sentence, "The quick brown fox jumps over the lazy dog", has the SHA-256 digest d7a8fbb3…37c9e592, and flipping one input bit changes 141 of its 256 bits, close to the half a good hash should change.
MD5 and SHA-1 have practical collision attacks, so use SHA-256 or SHA-512 wherever someone could tamper with the data.
How to hash text with SHA-256, MD5 or CRC-32
A hash function turns any input into a fixed-size digest, usually written in hex: 64 digits for SHA-256, 32 for MD5 and 8 for CRC-32. The same bytes always give the same digest, and changing even one bit gives a different one. SHA-256 of abc is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, the value in NIST's worked example.
Digest sizes and standards
MD5: 128 bits, 32 hex digits, defined in RFC 1321.
SHA-1: 160 bits, 40 hex digits.
SHA-256: 256 bits, 64 hex digits.
SHA-512: 512 bits, 128 hex digits.
CRC-32: 32 bits, 8 hex digits, the checksum used by zip, gzip and PNG.
SHA-1, SHA-256 and SHA-512 are specified in NIST FIPS 180-4. The length never depends on the input: one byte and 100,000 bytes both give 64 hex digits under SHA-256.
Test vectors for checking your code
Run these through a library or script before trusting it. Each input is plain ASCII with no trailing newline.
The quick brown fox jumps over the lazy dog, SHA-256: d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592
123456789, CRC-32: cbf43926, the standard check value for this CRC
If a downloaded file hashes to the empty-string digest, the file you hashed was empty.
Why the same text gives a different hash
A digest depends on the exact bytes, so text that looks identical can hash differently:
A trailing newline.echo abc | sha256sum hashes abc plus a line feed, 4 bytes, and prints edeaaff3…0efd18cb instead of ba7816bf…f20015ad. Use printf '%s' abc to hash the text alone.
Line endings. A file saved with Windows CRLF line endings has one more byte per line than the same text with LF endings.
Character encoding.é is 2 bytes in UTF-8 (C3 A9) but 1 byte in Latin-1 (E9), so the digests differ. Text here is hashed as UTF-8.
Unicode normalization. A precomposed é and an e followed by a combining accent look the same but take 2 and 3 UTF-8 bytes.
Hex versus Base64. Both write the same digest bytes: SHA-256 of abc in Base64 is ungWv48Bz+pBQUDeXa4iI7ADYaOWF3qctBD/YfIAFa0=, 44 characters. Base64-encoding the 64-character hex string gives an 88-character value instead, which fails a Subresource Integrity check.
Hex is case-insensitive, since BA78 and ba78 are the same bytes. Base64 is case-sensitive.
One flipped bit changes about half the digest
This avalanche effect is why near-identical inputs get unrelated digests. Each row flips the lowest bit of the first input byte and counts the digest bits that change:
Scenario
Input bytes
Digest bits
Changed bits
Default
43
256
141
sha256 abc
3
256
112
Added line feed
4
256
127
CRC check value
9
32
15
Unicode UTF-8
14
256
119
Default is the fox sentence under SHA-256. The other rows hash abc, abc plus a line feed, 123456789 under CRC-32, and héllo €😀, which is 8 characters but 14 UTF-8 bytes.
In an ideal hash each digest bit flips with probability one half, so single trials scatter around 128 of 256.
Integrity checks, not encryption
A hash is not encryption. There is no key and nothing to decrypt, yet anyone can hash likely inputs and compare. The SHA-256 of a phone number or a short password is easy to reverse by guessing.
MD5 and SHA-1 are broken for security.RFC 6151 rules out MD5 where collision resistance matters, and NIST is retiring SHA-1. Both still catch accidental corruption.
CRC-32 only detects accidents. Anyone can build different data with the same CRC, so use SHA-256 or SHA-512 wherever someone could tamper with the data.
Passwords need a slow, salted hash such as Argon2, bcrypt or PBKDF2, not one fast SHA-256 pass. The password entropy calculator covers the guessing side.
A checksum is only as trustworthy as its source. If an attacker can replace both a file and the checksum published beside it, a match proves nothing. A signed release covers that case.
What you can hash here
Text, encoded as UTF-8, up to 100,000 bytes. For files, run sha256sum (Linux), shasum -a 256 (macOS) or Get-FileHash (PowerShell).
A checksum to compare can be hex, with or without 0x and spaces, or Base64. A value that matches a different algorithm is reported as that algorithm's digest.
Text you type is written into the page address and its on-device history, so never paste passwords, keys or tokens.
To see the bytes behind a mismatch, use the text encoder.
Checked against: FIPS 180-4 / NIST CSRC SHA-512 two-block example
Questions
Is MD5 still safe to use?
Not for security. Practical MD5 collisions were published in 2004, and in 2008 researchers used them to forge a trusted certificate authority certificate. RFC 6151 (2011) says MD5 is no longer acceptable where collision resistance is required, such as digital signatures. It still catches accidental corruption in a download, but use SHA-256 or SHA-512 from NIST FIPS 180-4 for anything an attacker could alter.
What is the difference between SHA-1 and SHA-256?
SHA-256 produces a 256-bit digest (64 hex digits) against SHA-1's 160 bits (40 hex digits), and unlike SHA-1 it has no known practical collision attack. Google and CWI Amsterdam published the first SHA-1 collision, SHAttered, in 2017, and NIST has announced that SHA-1 is to be phased out of all its uses by 31 December 2030. Both belong to FIPS 180-4.
How do I verify a file's checksum?
Hash the downloaded file and compare the result with the checksum the publisher lists; any difference means the file changed. On Linux run sha256sum file, on macOS shasum -a 256 file, and on Windows certutil -hashfile file SHA256 or PowerShell's Get-FileHash, which uses SHA-256 by default. The comparison box here does the same for text and ignores case and spaces.
Why does echo text | sha256sum give a different hash?
Because echo adds a line feed, so the command hashes abc plus a newline (4 bytes) rather than abc (3 bytes), and one extra byte changes the whole digest: SHA-256 of abc starts ba7816bf, while abc with a line feed starts edeaaff3. Use echo -n or printf '%s' to hash the text alone, or turn on the line-feed option here to match echo.
Can two different inputs have the same hash?
Yes, because unlimited inputs map to a fixed number of digests, but for a secure hash nobody should be able to find such a pair. By the birthday bound, a brute-force search needs about 2^(n/2) tries for an n-bit digest: 2^64 for MD5 and 2^128 for SHA-256. Known attacks find MD5 and SHA-1 collisions far faster, and CRC-32 collisions can be computed directly because CRC is linear.
This calculator includes 11 worked examples with independently sourced answers. They run in the test suite, and you can run them here too.
Put this calculator on your site
Paste this where you want the calculator to appear. It is free to use, it stays in step with corrections made here, and the credit line below it links back so your readers can find the full version.