SHA-256 Generator

The workhorse hash of the modern internet: what those 64 hex characters actually say about your data, how to verify a download against a published checksum, why identical-looking text can hash differently, and where SHA-256 stops being the right tool.

What SHA-256 computes

SHA-256 reads any input, one byte or ten gigabytes, and produces a 256-bit digest, always 64 hex characters. It belongs to the SHA-2 family, specified by NIST in FIPS 180-4, and three properties make it useful. The output is deterministic: the same bytes produce the same digest on every machine, every time. It is one-way: no computation recovers the input from the digest. And it avalanches: flip a single input bit and on average half the output bits flip with it.

The sample sentence above, the quick brown fox, hashes to d7a8fbb3…; add a period at the end and every character of the output changes. That sensitivity is the point. A digest that matches proves the data is bit-for-bit identical, and one that differs proves it is not, without saying where or by how much.

How to use this generator

1. Hash text: type or paste and the digest updates live. The input is read as UTF-8, the same convention sha256sum, Python and Node use, so results are comparable.
2. Hash a file: drop it on the input pane. The raw bytes are hashed, not a text rendering of them, so binaries, images and archives come out right. The download button then produces a checksum file in coreutils format, which sha256sum -c accepts directly.
3. Verify: paste the expected hash into the verify field. Uppercase, colon-separated fingerprints and full checksum-file lines all parse. On a mismatch the note under the result names the first differing character; on a length mismatch it names the algorithm your paste probably came from, because comparing a SHA-1 against a SHA-256 is the most common verification mistake there is.

--base64 switches the output to the encoding Subresource Integrity and AWS APIs expect, --uppercase matches how certutil prints digests on Windows. Both are display choices; the underlying 32 bytes are identical.

Verifying a download, and why it fails when it fails

The verification workflow is short: hash the file you received, compare against the value the publisher lists. When the comparison fails on a file you are sure is right, the cause is almost never the hash function. In our experience it is one of four bytes-level differences: a CRLF that Git or an editor swapped in for LF, a trailing newline appended by a shell redirect, a UTF-8 byte order mark hiding at offset zero, or a proxy that transparently decompressed the file you were checksumming compressed. The mismatch note this tool shows points at the first differing character, which separates "completely different input" (differs at character 1, usually the line-ending case) from "you pasted the wrong half of a long checksum list".

$ printf 'abc' | shasum -a 256; echo 'abc' | shasum -a 256
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad  -
edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb  -

Worth stating the limit too: a checksum verifies integrity, not origin. It proves the file matches the published hash, and nothing about who published it. When both file and checksum come from the same server, an attacker who controls the server updates both. Signed releases (GPG, minisign, Sigstore) close that gap; a checksum alone does not.

MD5, SHA-1, SHA-2 side by side

The pattern in the table repeats across hash history: collisions arrive first as an academic paper, then as a tool anyone can run. MD5 went from broken in theory to broken on a laptop within a few years, SHA-1 followed the same arc a decade later. SHA-256 shows no signs of starting down that path, and its 256-bit length means even the first crack would leave a wide safety margin. When you have a choice today, this is the default; the SHA-512 page covers when the longer sibling earns its keep.

Where SHA-256 shows up

Once you look for it, it is everywhere: TLS certificates are signed over their SHA-256 digest, Bitcoin mines by grinding double SHA-256, Docker addresses image layers by it, Debian and every serious package manager checksum their archives with it, Git can now run repositories on it instead of SHA-1, and the integrity="sha256-…" attribute on a script tag is its Base64 form. The shared idea is content addressing: the digest is a fingerprint that names the exact bytes, so equality of names proves equality of content.

Its keyed relative is worth knowing about: when two parties share a secret and want to prove a message came from one of them, the construction is not sha256(secret + message) but an HMAC, for reasons the HMAC generator page walks through.

Not for passwords

The one job SHA-256 is regularly given and should not have is storing passwords. The problem is its best feature: speed. A single GPU computes billions of SHA-256 hashes per second, so an unsalted, fast-hashed password database falls to a dictionary attack in hours. The fix has two parts. A salt, random bytes stored next to each hash, stops precomputed tables and forces the attacker to crack every account separately. And a deliberately slow algorithm (bcrypt, scrypt, Argon2) turns those billions of guesses per second into hundreds of thousands or less.

Both parts come built into the bcrypt generator, where you can watch the cost factor make hashing measurably slow, and our password hashing guide covers choosing between bcrypt, scrypt and Argon2 in production.

SHA-256 questions