SHA-256 produces a 256-bit output from an input of any length. Change one character in a 10,000-word document and the output changes completely — unpredictably, across all 64 hex characters. 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. Use the SHA-256 Hash Generator to follow along with the examples in this guide.
Background: The SHA Family
NIST has published four generations of Secure Hash Algorithms:
SHA-0 (1993): The original, withdrawn within a year due to an undisclosed flaw identified by the NSA.
SHA-1 (1995): 160-bit output. Used extensively in TLS, SSH, and Git. A practical collision attack was demonstrated by Google's Project Zero in 2017 (the SHAttered attack). SHA-1 is deprecated for all new security uses. Our SHA-1 Hash Generator exists for legacy verification only.
SHA-2 (2001): A family of hash functions — SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. All remain unbroken as of 2025. SHA-256 is the most widely deployed. SHA-512 offers 512-bit output with different internal constants; 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 standardised it as a backup with a different design. SHA-3 generates hashes in the same size ranges as SHA-2 but is not a drop-in replacement (different output for the same input).
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.
How SHA-256 Works
Step 1 — Pre-processing and 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: append a 1 bit, then enough 0 bits to make the message length 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 + 1 + 423 (zeros) + 64 (length) = 512 bits. One block.
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). This method of deriving constants from a reproducible mathematical source (prime roots) is called the "nothing-up-my-sleeve" principle — it demonstrates no hidden trapdoor was embedded in the constants.
Step 3 — Message schedule expansion
Each 512-bit block is expanded into 64 32-bit words (W[0] through W[63]). The first 16 words come directly from the message block. The remaining 48 words are computed using a mixing function involving bit rotations and XOR operations on earlier words in the schedule. This is the message schedule expansion.
Step 4 — 64 rounds of compression
The compression function maintains eight working variables a through h. For each of the 64 rounds, two bitwise mix functions (Sigma0, Sigma1, using bit rotations and XOR) produce intermediate values that update all eight working variables. Each round also adds a round constant K[i] — the fractional part of the cube root of the ith prime number (there are 64 such constants). 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–h7 are concatenated to produce the 256-bit final hash. Written as hexadecimal, this is 64 characters.
Practical Applications
Git commit IDs: Every Git commit is identified by a SHA-1 hash of its content (Git is migrating to SHA-256 via the object format v2 transition). The hash uniquely identifies the exact content of a commit tree, making tampering detectable.
Bitcoin mining: Bitcoin block headers include a target difficulty value. Miners are required to find a nonce value 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 specialised hardware — the SHA-256 computation must be performed trillions of times per second across the network.
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 (CT logs) record fingerprints of all issued certificates, allowing detection of misissued or malicious certificates.
Limitations
Password storage: SHA-256 is fast by design — a single GPU can compute 4–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. Use a purpose-built password hashing function with a work factor: bcrypt (cost factor), scrypt (N, r, p parameters), or Argon2 (memory and time costs). These are deliberately slow.
No known practical collision attack: As of 2025, no practical collision (two different inputs producing the same SHA-256 output) has been found. The algorithm is considered secure for integrity verification, digital signatures, and HMAC.
SHA-1 is broken: The SHAttered attack demonstrated a practical SHA-1 collision in 2017. 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.