Change one letter, change half the digest

Type in both boxes and watch what a single character does to a SHA-256 hash. About half the bits flip, every time, no matter how small the change — that property is called the avalanche effect and it is most of why hashes are useful.

HomeCryptography & Security › Hash Avalanche

of the 256 bits differ
The same two digests, bit by bit

Differing bits are marked. Look for patterns — there are none, which is the point.

Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.

Why it is not exactly 50% every time, and should not be

The avalanche property says that flipping one bit of the input should flip each output bit with probability one half, independently. That is a statement about the distribution, not a guarantee about any particular pair.

Over 256 bits, the number that differ follows a binomial distribution: the average is 128 and the standard deviation is 8. So results between about 112 and 144 — roughly 44% to 56% — are entirely ordinary, and you will see them constantly on this page. A hash function that produced exactly 128 every single time would be exhibiting a pattern, and a pattern is exactly what must not be there.

What would be alarming is a consistent bias — always above 60%, or always below 40%, or a particular byte that never changes. Try as many pairs as you like; SHA-256 does not do that.

What this property buys you

You cannot work backwards from a small difference. If similar inputs gave similar digests, an attacker could hill-climb: guess, see how close the digest is, adjust, repeat. The avalanche effect destroys that gradient — a guess that is nearly right produces a digest that is no closer than a guess that is completely wrong.

Tiny changes cannot hide. A single altered byte in a file gives a completely different digest, so there is no such thing as a change too small to notice. This is what makes checksums work.

The digest reveals nothing about the input. Not its length, not its content, not whether two inputs are similar. That last one matters: given only digests, you cannot tell whether two documents differ by a word or entirely.

Try the trailing space

Press the button and add a single space to the end of one input. The digests are unrelated. This is behind a great many confusing failures: a file that gained a newline when it was saved, a string trimmed on one side of a system and not the other, a copy-paste that picked up whitespace. The hash is not being unhelpful — it is doing precisely its job, which is to treat "nearly the same" as "not the same".

Where this comes from

The term is Horst Feistel's, from IBM in the 1970s, describing what a good block cipher should do: a change in one input bit should cascade so that roughly half the output changes. The strict avalanche criterion, defined later, is the precise version — each output bit flips with probability exactly one half when any single input bit flips.

Modern hash functions are built to satisfy it by construction, through many rounds of mixing where each round spreads local changes further across the state.

Related

The hash calculator for real files, classical ciphers to see what happens when a design does not have this property, or entropy for what "256 bits" is actually worth.

Questions people actually ask

Why is it not exactly 50% every time?

Because the avalanche property is about a distribution, not a guarantee for any particular pair. The number of differing bits follows a binomial with mean 128 and standard deviation 8, so anything from about 112 to 144 is completely ordinary. A hash that gave exactly 128 every single time would be showing a pattern, which is the thing that must not be there.

What would a broken hash look like here?

A consistent bias: always well above or below half, a byte that never changes, or a visible relationship between how similar the inputs are and how similar the digests are. SHA-256 shows none of those however many pairs you try.

Why does adding a space change everything?

Because the hash treats "nearly the same" as "not the same", which is exactly its job. It is behind a lot of confusing failures — a file that gained a newline on save, a string trimmed on one side of a system and not the other — and in every case the hash is working correctly.

What is this property actually for?

It removes the gradient an attacker would otherwise climb. If similar inputs gave similar digests you could guess, measure how close you got, adjust and repeat. With avalanche, a nearly-correct guess is no closer than a completely wrong one. It also means no change to a file is too small to detect.

Could two different inputs give the same digest?

In principle yes — there are more possible inputs than digests. In practice nobody has found a SHA-256 collision and nobody expects to; it would take vastly more computation than exists. For MD5 and SHA-1 collisions can be produced deliberately, which is why neither should be used to establish that a file is the one you expect.

Is what I type sent anywhere?

No. Both hashes are computed in your browser by its own Web Crypto implementation.