What does SHA-256 do to its input?

How does the mechanism work?

SHA-256 produces 256 bits, commonly shown as 64 hexadecimal characters. Spaces, line breaks and letter case change the input bytes. Text must first be encoded into bytes, so the encoding is part of a reproducible example.

Bitcoin uses hashes in several places. For proof of work, it applies SHA-256 twice to the serialized block header. A single hash of a text message helps explain determinism, but it is not a block-mining simulation.

A hash commitment is useful only when you know which bytes were committed. A label such as transaction or header does not define its serialization by itself. Field ordering, integer encoding and inclusion of witness data can all matter in the appropriate context. Start with a specification, construct its required byte sequence and only then apply the hash function. When a digest differs, compare those inputs before assuming the cryptographic primitive is unreliable. This method turns debugging into a reproducible process: inspect the bytes, check a known-answer vector and distinguish raw results from the way an interface displays them.

What does a known input let you verify?

A worked example needs exact bytes. The lowercase text abc encoded as UTF-8 is the hexadecimal byte sequence 61 62 63. Its SHA-256 digest is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. This known-answer vector lets you check an implementation without relying on whether the result looks random. A trailing newline would be another message.

SHA-256 processes data in 512-bit blocks after its specified padding. That is 64 bytes per processing block; it is unrelated to a Bitcoin block full of transactions. The final digest is 32 bytes. For the short abc example, padding completes the processing block before the compression function produces the digest. You do not manually add those padding bytes when using the local demo.

For Bitcoin header hashing, the input is the serialized 80-byte header. Apply SHA-256 to those bytes, then apply SHA-256 again to the resulting 32 digest bytes. Hashing the displayed hexadecimal characters of the first digest instead would change the second input. The characters and the raw digest bytes represent related information but are different byte strings.

When comparing a displayed block hash with a low-level calculation, byte-order conventions also matter. Establish which serialization the source used and how it displays the result. A mismatch in display order is not a failure of deterministic hashing. The local text demo intentionally avoids block serialization so you can isolate the simpler question of whether identical text bytes give an identical digest.