How SHA-256 Works: A Step-by-Step Walkthrough for Developers

SHA-256 takes an input of any length and produces exactly 256 bits of output: 32 bytes, written as 64 hexadecimal characters. Feed it a single letter or a 10,000-word document and the output size is identical. Change one character in that document and every one of the 64 hex characters changes, unpredictably and with no visible relationship to the edit. This is the avalanche effect, and it is the property that makes SHA-256 useful for integrity verification.

The algorithm is formally defined in NIST FIPS 180-4 (Secure Hash Standard, National Institute of Standards and Technology, 2015). It is not proprietary, not patented, and not secret. The specification is publicly available in full. A sibling standard, NIST FIPS 202 (SHA-3, based on the Keccak sponge construction), defines a separate family of hashes that serve as a backup design. Use the SHA-256 Hash Generator to follow along with the examples in this guide.

NIST has published four generations of Secure Hash Algorithms. Understanding where SHA-256 sits in that history explains why it is the default choice for new systems.

SHA-0 (1993): The original 160-bit hash, withdrawn within a year after an undisclosed flaw was identified by the NSA.

SHA-1 (1995): Also 160-bit output. Used extensively in TLS, SSH, PGP, and Git for two decades. It is now fully broken and must not be used for signatures. The SHAttered attack (2017, Google Project Zero and CWI Amsterdam) produced the first practical collision: two distinct PDF files with the same SHA-1 hash. Three years later, Leurent and Peyrin demonstrated the first chosen-prefix collision in "SHA-1 is a Shambles" (2020), renting GPUs for about $45k to forge a PGP Web of Trust identity (CVE-2019-14855). A chosen-prefix collision is worse than a random collision because the attacker controls both inputs, enabling targeted impersonation. Our SHA-1 Hash Generator exists for legacy verification only.

SHA-2 (2001): A family of hash functions with shared internals: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. All remain unbroken as of 2026. SHA-256 is the most widely deployed. SHA-512 offers 512-bit output with 64-bit word operations; our SHA-512 Hash Generator generates those.

SHA-3 (2015): Based on the Keccak sponge construction, a completely different algorithm from SHA-2. No known weakness in SHA-2 prompted SHA-3. NIST standardized it as a backup with a different design so that a future break in the Merkle-Damgard construction used by SHA-2 would not take down every standardized hash. SHA-3 generates hashes in the same size ranges as SHA-2 but is not a drop-in replacement: the same input produces a different output.

For password storage specifically, SHA-256 and all SHA-2 variants are designed to be fast. That is good for integrity verification. It is bad for passwords, because an attacker with a GPU can compute billions of SHA-256 hashes per second. Use bcrypt, scrypt, or Argon2 for passwords. Our bcrypt Hash Checker demonstrates the format.

SHA-256 is a Merkle-Damgard construction with a Davies-Meyer compression function. The input is processed in 512-bit blocks through 64 rounds of mixing. Here is what happens at each stage.

Step 1: Padding

SHA-256 processes input in 512-bit (64-byte) blocks. If the input is not a multiple of 512 bits, it is padded. The padding scheme has three parts: append a single 1 bit, then append enough 0 bits to bring the message length to 448 bits mod 512, then append the original message length as a 64-bit big-endian integer. The result is always a multiple of 512 bits.

Example: the string "abc" is 24 bits. After padding: 24 (data) + 1 (the appended 1 bit) + 423 (zero bits) + 64 (length field) = 512 bits. One block.

`` "abc" = 0x616263 padded = 61626380 00000000 ... 00000018 ^^^^^^ ^zeros^ ^length=24^ ``

Step 2: Initial hash values

SHA-256 starts with eight 32-bit initial hash values, h0 through h7. These are the fractional parts of the square roots of the first eight prime numbers (2, 3, 5, 7, 11, 13, 17, 19). For example, h0 is the fractional part of the square root of 2, which is 0x6a09e667. Deriving constants from a reproducible mathematical source is called the "nothing-up-my-sleeve" principle. It demonstrates that no hidden trapdoor was embedded in the constants, because anyone can recompute them from the primes.

Step 3: Message schedule expansion

Each 512-bit block is split into 16 32-bit words, W[0] through W[15], taken directly from the block. These 16 words are then expanded into 64 words (W[0] through W[63]) using a mixing function. For i from 16 to 63:

`` W[i] = W[i-16] + σ0(W[i-15]) + W[i-7] + σ1(W[i-2]) ``

where σ0 and σ1 are fixed combinations of right-rotations and XOR. This expansion ensures that every bit of the input influences many rounds of the compression function, which is what produces the avalanche effect.

Step 4: 64 rounds of compression

The compression function maintains eight working variables, a through h, initialized from the current hash values. For each of the 64 rounds, the function computes two intermediate values using bitwise mix functions (Sigma0, Sigma1, Ch, Maj, all built from rotations and XOR), adds the current message schedule word W[i], and adds a round constant K[i]. The round constants are the fractional parts of the cube roots of the first 64 prime numbers, another nothing-up-my-sleeve construction. After each round, the eight working variables are rotated: a becomes the new output, and the old values shift down. After 64 rounds, the working variables are added (mod 2^32) to the initial hash values. The output of one block becomes the input hash values for the next block.

Step 5: Final output

After all blocks are processed, the eight 32-bit hash values h0 through h7 are concatenated to produce the 256-bit final hash. Written as hexadecimal, this is 64 characters. For "abc" the output is:

`` ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad ``

Git commit IDs: Every Git commit is identified by a hash of its content. Historically Git used SHA-1, but Git is migrating to SHA-256. The SHA-256 object format has not been experimental since 2023, and Git plans to make SHA-256 the default in Git 3.0. GitHub and other forges are still adding support, so most repositories today still use SHA-1. The hash uniquely identifies the exact content of a commit tree, making tampering detectable: change one byte in a committed file and the commit hash changes completely.

Bitcoin mining: Bitcoin block headers include a target difficulty value. Miners must find a nonce such that SHA-256(SHA-256(block header)) produces a hash below the target. This double-SHA256 proof of work is why Bitcoin mining requires specialized hardware. As of 2026, the network hashrate is around 900 EH/s (exahashes per second) with difficulty around 126 trillion. The block subsidy is 3.125 BTC after the April 2024 halving. Miners compute the double hash trillions of times per second, and modern ASICs reach around 9.5 J/TH (joules per terahash) efficiency.

HMAC-SHA256 in API authentication: Many REST APIs authenticate requests with an HMAC (Hash-based Message Authentication Code) using SHA-256. The server and client share a secret key. The client computes HMAC-SHA256(key, request body) and sends it as a header. The server recomputes it and compares. Any tampering with the request body changes the HMAC. Our HMAC Generator supports HMAC-SHA256.

TLS certificate fingerprints: The SHA-256 fingerprint of a TLS certificate is a 64-character hex string. Certificate transparency logs record fingerprints of all issued certificates, allowing detection of misissued or malicious certificates.

Password storage: SHA-256 is fast by design. A single modern GPU can compute 4 to 8 billion SHA-256 hashes per second. An attacker with a leaked hash database and a password list can check hundreds of millions of common passwords in seconds. Never use raw SHA-256 for passwords. OWASP recommends Argon2id first, then bcrypt or scrypt. These are deliberately slow and memory-hard, making large-scale offline cracking prohibitively expensive. Our bcrypt Hash Checker shows the bcrypt format in practice.

Collision status: Full 64-round SHA-256 has no practical collision attack as of 2026. The best published attacks only break reduced-round versions: a 37-step collision attack (EUROCRYPT 2026) and a 35-step practical collision (CRYPTO 2026). Full SHA-256 uses 64 rounds, so these results do not threaten the real algorithm. SHA-256 remains secure for integrity verification, digital signatures, and HMAC.

SHA-1 is broken: The SHAttered attack (2017) and "SHA-1 is a Shambles" (2020) demonstrated that SHA-1 is broken for any security-sensitive use. If you are verifying SHA-1 file hashes for security purposes, migrate to SHA-256. The MD5 Hash Generator is similarly legacy only: MD5 collisions have been computationally feasible since 2004.