Why changing one character changes the whole hash

Alter one letter and roughly half the bits of the digest flip. Not a few — half.

Type "cat", then change it to "cau", and the two digests have nothing visibly in common. This is called the avalanche effect, and it is a designed property rather than a happy accident.

Step-by-step

1. Type something. Its SHA-256 appears.
2. Change one character.
3. Watch the bits that flipped, marked, with a count.

Why half is the right answer

A good hash should behave, as far as any observer can tell, like a function that assigns a completely random output to every input. If that is true, then changing the input gives you an unrelated random output — and two unrelated 256-bit values agree on about half their bits by chance.

So half is not a target the designers aimed at directly. It is what falls out of the output being indistinguishable from random. If a small input change flipped only a few bits, an attacker could work backwards from similar outputs to similar inputs, and the function would be useless.

Why it is never exactly half

128 of 256 is the average, not the rule. Any particular pair gives something near it — 121, 133, 127 — scattered around the middle exactly as coin flips scatter. A hash that produced exactly 128 flipped bits every single time would be exhibiting a pattern, and a pattern is a weakness. The tool reports the actual count rather than rounding it to a tidy claim.

What this is good for

It explains why digests are useful for verifying downloads: no partial corruption produces a nearly-correct digest, so there is no such thing as a near miss. It also explains why hashes cannot be reversed by working from something close — there is no "close" in output space.

And it explains why plain hashes are wrong for passwords. The avalanche effect makes each guess unrelated to the last, but it does not make guessing slow, and speed is what password storage needs to prevent.

Frequently asked questions

Why is it not exactly half the bits every time?

Because the outputs behave like independent random values, and independent random values agree on about half their bits on average, with ordinary variation around it. A fixed count would itself be a detectable pattern.

Does this apply to all hashes?

It applies to any hash function considered sound, including the whole SHA-2 family. Broken functions like MD5 still show avalanche behaviour on casual inspection, which is a reminder that looking random is not the same as being secure.

Can I get the input back from a digest?

No. The function discards information — any amount of input produces the same output length — so there is nothing to reverse. Attacks work by guessing inputs and comparing, which is why slow functions are used for passwords.