Understanding SHA-256: from bytes to a hash

The short answer

SHA-256 calculates a 256-bit hash from an input: 64 characters in hexadecimal. Identical input bytes produce the same hash. Comparing hashes therefore helps compare a file with a known reference. Alone, it says neither who created the file nor whether its content is correct or harmless.

This article develops part of my teaching guide “Wie Computer funktionieren”. I am interested in its practical connection: anyone using a checksum for downloads, backups or logs should be able to explain which question it answers.

Why 256 bits produce exactly 64 hexadecimal characters

A bit has two possible values. Four bits have 16 patterns, matching hexadecimal digits 0 to F. One hex digit therefore represents four bits. For SHA-256 this means:

256 Bits / 8 = 32 Bytes
256 Bits / 4 = 64 Hexzeichen

The character string is a representation of the result, not a compressed original file. Even a huge file produces the same output length. The file cannot generally be recovered from that short value.

A concrete calculation makes this tangible: one byte contains eight bits and 256 possible patterns. Two hexadecimal digits represent these, from 00 to FF. A 32-byte hash therefore needs 32 pairs. Letter case does not change the represented numerical values.

Visible text is not yet the input

For text, establish exactly which bytes are hashed. Character encoding turns characters into bytes; line endings are also part of the file. The three ASCII characters abc consist in UTF-8 of the bytes 61 62 63.

abc ohne Zeilenende: 61 62 63
abc mit LF:         61 62 63 0A
abc mit CRLF:       61 62 63 0D 0A

These are three different inputs. If two tools return different values, I would first check the bytes: was a line ending added, was another encoding used, or is there a byte-order mark? Identical-looking text can be encoded differently.

For the three bytes 61 62 63 the SHA-256 value is:

ba7816bf8f01cfea414140de5dae2223
b00361a396177a9cb410ff61f20015ad

Both lines belong together; the break is only for readability. You can calculate the same value in the browser below. The detailed file exercise is in Checking files with PowerShell.

What happens in the algorithm

The NIST Secure Hash Standard describes the precise process. In simplified terms, SHA-256 appends padding and the original message length, then divides the padded message into 512-bit blocks. Each block passes through 64 rounds using 32-bit words, bit operations and addition modulo 2 to the power of 32. The evolving state finally yields the 256-bit output.

These sizes answer different questions: 512 bits describe a block, 32 bits the words, and 256 bits the result. The number 64 occurs both for rounds and hexadecimal representation, but means different things.

This is an explanation of the process. For applications I would use an established library. A learning implementation can clarify the algorithm, but must be distinguished from a reviewed production implementation.

What a comparison establishes

Suppose I retain the checksum of a PDF edition and later hash a received file. A different value shows that its byte sequence differs. Why remains open: an exporter might have changed only metadata, or the visible content may have changed.

Under usual cryptographic assumptions, a matching value strongly indicates identical bytes. It is not a mathematical uniqueness proof for all files: different inputs can share an output. The practical requirement is that deliberately finding such collisions should be computationally infeasible.

The reference value’s origin is decisive. If an attacker replaces both file and published checksum, they match again. A comparison with an independently trusted reference establishes more than comparing with an arbitrary value on the same unknown site.

Limits that matter in a project

Hashing does not encrypt data. Hashing private content does not make its original file confidential, and a hash alone is not a digital signature. I explain the distinction in Hashing, encryption and signatures.

A chained log also needs a trusted anchor. Someone able to rewrite the whole chain and recalculate every hash can create a different, internally consistent history. For belegwerk this limit is important to understanding the register. Hashing checks neither sources nor responsibility for the original input.

One fast SHA-256 pass is unsuitable for storing passwords. That requires salted methods with deliberately increased computation or memory cost. The OWASP password storage recommendations address this task separately.

Three questions for your own use

1. Which exact file or byte sequence is checked?
2. Where does the trusted reference value come from?
3. What should the comparison establish: unchanged bytes, origin or substantive correctness?

If the third question has several answers, the workflow usually needs several checks. For me, good cryptographic practice starts by distinguishing these expectations.