The Complete Guide to SHA-256 Hashing

Q: Hash output differs between tools

Check encoding. `echo "hello"` adds a trailing newline; `echo -n "hello"` doesn't. That one `\n` changes the hash completely. Also verify both sides use UTF-8 — Latin-1 and UTF-16 encode the same characters as different bytes.

This page is extra context on top of the full article under the tool. Nothing here replaces that copy — it adds the SHA-2 family breakdown, algorithm comparisons, and production code examples.

SHA-256 in the SHA-2 family

SHA-2 was designed by the NSA and published by NIST in 2001 as FIPS 180-2. The family includes several variants:

Variant	Word size	Rounds	Output
SHA-224	32-bit	64	224 bits
SHA-256	32-bit	64	256 bits
SHA-384	64-bit	80	384 bits
SHA-512	64-bit	80	512 bits
SHA-512/224	64-bit	80	224 bits
SHA-512/256	64-bit	80	256 bits

SHA-256 processes input in 512-bit blocks through 64 rounds of compression using 32-bit words. All SHA-2 variants remain cryptographically secure as of 2025.

SHA-3 and BLAKE3: the alternatives

SHA-256 is the safe default, but two newer algorithms are worth knowing:

Algorithm	Output	Speed	Notes
SHA-3 (Keccak)	256-bit	Moderate	Completely different internals (sponge construction). Less deployed but offers diversity if SHA-2 ever falls.
BLAKE3	256-bit	Very fast	Parallelizable, tree-based. Newer, gaining adoption. Great for file hashing at scale.

If you need speed for large files, look at BLAKE3. If you need algorithmic diversity (defense in depth), SHA-3 is there.

Where SHA-256 is used

It's everywhere:

Git — commit hashes (currently SHA-1, migrating to SHA-256)
Bitcoin — proof-of-work requires finding a nonce where SHA-256(SHA-256(block)) starts with enough zeros
TLS — certificate fingerprints and signature algorithms
Subresource Integrity (SRI) — <script integrity="sha256-abc123...">
Docker — image digests: sha256:a3ed95caeb02...
npm — package integrity checks in package-lock.json
Content-addressable storage — same content → same key, deduplication is free

Using SHA-256 in code

Browser (Web Crypto API):

async function sha256(text) {
  const data = new TextEncoder().encode(text);
  const buf = await crypto.subtle.digest("SHA-256", data);
  return Array.from(new Uint8Array(buf))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
}

Node.js:

const crypto = require("crypto");
const hash = crypto.createHash("sha256").update("hello").digest("hex");

Command line:

echo -n "hello" | shasum -a 256
# 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Note the -n flag — without it, echo appends a newline, which changes the hash entirely.

Troubleshooting

Hash output differs between tools — Check encoding. echo "hello" adds a trailing newline; echo -n "hello" doesn't. That one \n changes the hash completely. Also verify both sides use UTF-8 — Latin-1 and UTF-16 encode the same characters as different bytes.

Can I reverse a SHA-256 hash? — No. SHA-256 is a one-way function. You can't mathematically reverse it. Lookup databases (rainbow tables) exist for common strings like password123, but for arbitrary input, reversal is computationally infeasible — the search space is 2²⁵⁶.

Two files have the same hash — If they're the same file, that's expected. If they're genuinely different files with the same SHA-256 hash, you've found a collision — which has never been demonstrated for SHA-256. Check that you're hashing the file contents, not just the filename or path.

Hash is different when I hash the same string on different platforms — Text encoding matters. Ensure both platforms use UTF-8. Check for BOM (byte order mark), trailing newlines, or line ending differences (CRLF on Windows vs LF on Unix).