Hashing explained: change one character and inspect the result

A fingerprint for bytes

Suppose you write a tiny note: hello. You want a compact value that another reader can recompute to check whether their copy matches yours. A cryptographic hash takes the note’s bytes and produces a digest. For SHA-256, the digest is always 256 bits, or 32 bytes.

We normally print those bytes as 64 hexadecimal characters. Hex uses the digits 0–9 and letters a–f; each character represents four bits. A longer printed digest does not mean the original message was longer.

For the UTF-8 bytes of hello, SHA-256 begins 2cf24dba. The full result is displayed below. The same bytes always produce the same digest. That repeatability is why two readers can compare independent calculations.

Make a prediction

Change the first letter to make Hello. Would you expect just the first character of the digest to change? Would adding a whole paragraph make the digest longer?

Try both. The experiment runs the browser’s real SHA-256 function. The colored tiles compare each hex character with the baseline hello; the accompanying number counts changed bits, which is a different measure. We do not manufacture a visually pleasing “half the bits” result.

A small input change usually changes many output bits. This does not imply that every possible edit changes exactly half, or that the visual pattern is itself a security proof.

A digest cannot carry everything about a message

There are only finitely many 256-bit outputs, and far more possible messages. Different messages must sometimes share a digest. That is a collision. The useful security property is the difficulty of deliberately finding one, not the mathematical impossibility of its existence.

Similarly, “one way” does not mean a short predictable message is secret. If the only candidates are yes and no, an observer can hash both and compare. No inversion algorithm is needed. A digest can therefore be useful for identifying data while being completely unsuitable for hiding a low-entropy answer.

The input here is UTF-8 text. A newline, trailing space, or different Unicode representation changes the bytes. If two applications need identical hashes, they must agree on the exact byte representation first. That agreement is part of the design, not a courtesy the hash function supplies.

A digest also needs a trusted comparison point. If an attacker replaces both a download and the digest beside it, the two can still agree. The hash only answers whether the supplied bytes match the supplied reference.

Reproduce the calculation

In a browser console on HTTPS or localhost, run this with a fictional message:

const bytes = new TextEncoder().encode('hello');
const result = await crypto.subtle.digest('SHA-256', bytes);
const hex = Array.from(new Uint8Array(result),
  byte => byte.toString(16).padStart(2, '0')).join('');
console.log(hex);

Expected result:

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Now hash an empty string. Empty input still has a digest; it is not an error or a string of zeros. Next compare hello with hello , which has a trailing space. The latter is six ASCII/UTF-8 bytes.

This exercise uses one SHA-256 operation. Bitcoin uses hashing in several contexts with specific serialization and, in some places, repeated hashing. This text lab is neither a transaction identifier calculator nor a mining implementation.