SHA-256 hash generator

A SHA-256 digest is 64 hexadecimal characters, and the box above will produce one for any string you put in it — an API key you are checking, a line out of a config file, a token somebody pasted into a ticket, a value you have been asked to confirm. What follows is what those 64 characters are, how the algorithm arrives at them, and why the same text saved as a file comes back with a different answer.

How this page works

The calculation happens in your browser. Whatever is in the box is encoded as UTF-8 and hashed in the tab on every keystroke, and the byte count beneath it counts the encoded bytes rather than the characters — which is why one emoji moves it by four. Nothing is sent anywhere and nothing is kept; close the tab and the only copy of what you typed goes with it.

You can prove that claim rather than take it on faith. Open your browser's network inspector, type something, and watch nothing happen. Or disconnect from Wi-Fi and reload: the page carries on working, because there is nothing for it to call.

What the page will not do is read a file off your disk, and that is worth knowing before you start. This box is for text — a string, a line out of a config file, an API key, a token somebody pasted into a ticket, a value you have been asked to confirm. A file is a different job, and the last section of this page says where it belongs.

What SHA-256 actually gives you

SHA-256 takes an input of any length and returns exactly 256 bits — 32 bytes, written as 64 hexadecimal characters. Three properties make it useful:

• It is deterministic. The same bytes always produce the same digest, on any machine, in any decade. That is what makes it a fingerprint rather than a checksum of convenience.
• It is one-way in practice. There is no known method of recovering the input from the digest that beats trying inputs one at a time.
• Nobody can construct a collision. No two different inputs with the same SHA-256 digest have ever been found, and none is expected to be. This is the property MD5 and SHA-1 have lost, and it is the one that makes a digest usable as proof of identity.

One consequence surprises people: change a single bit of the input and roughly half the bits of the digest change with it, which in hexadecimal alters almost every character. There is no sense in which two digests can be nearly equal, so comparing the first and last few characters of a long hash is not the shortcut it looks like — though in practice it is a reasonable eyeball check, because an accidental corruption has no way to preserve them.

How any input becomes 32 bytes

Before anything is hashed the input is padded: a single 1 bit, then zeros, then the original length in bits written as a 64-bit number, carried on until what is left divides exactly into 512-bit blocks. That trailing length field is the reason you cannot quietly extend an input with zeros and land on the same digest, and it is also why cost is linear — a megabyte of input takes almost exactly a thousand times as long as a kilobyte, because it is a thousand times as many blocks.

Each block then runs 64 rounds of additions, rotations and exclusive-ors over eight 32-bit words of state, which begin from the fractional parts of the square roots of the first eight primes. Whatever that state holds after the last block is the digest, written out as 64 hexadecimal characters — nothing is held back at the end, which is the detail that makes length-extension attacks possible against homemade “hash the key, then the message” constructions, and exactly what SHA-384 changes by publishing only six of its eight words.

Why a file's digest differs from the same text

Hashing text and hashing a file are different operations and they give different answers, which accounts for a great deal of confusion.

Hashing text hashes exactly the characters you typed, encoded as UTF-8, with nothing added. Hashing a file hashes every byte on disk — including a trailing newline your editor added, including a byte-order mark, including Windows CRLF line endings if that is what the file contains. A one-line text file almost never has the same digest as the line typed into the box above, and the culprit is nearly always a final newline.

If you are comparing against a value something else produced, a trailing newline is almost certainly your answer, and the byte count is what gives it away: abc is three bytes, and abc with a newline after it is four. The Text tool of Rocket Hash keeps that count on screen directly above the digests for exactly this reason — you can watch it go from three bytes to four as the stray character lands — and clicking a digest row copies that one value whole, so the byte count never travels with it. Hashing text on a Mac works through the encoding details that decide the answer, and why two tools disagree covers the other five causes.

Where you will meet SHA-256

• Download verification. Linux ISOs, installers, firmware images and release archives nearly all publish a SHA-256. When a page just says “the checksum”, this is what it means.
• Git, after SHA-1. Git's object model is migrating from SHA-1 to SHA-256 for exactly the collision reason above.
• TLS certificates. The signature on virtually every certificate your Mac trusts is over a SHA-256 digest.
• Bitcoin and friends. Proof of work is SHA-256 applied twice, several quintillion times a second, worldwide.
• Deduplication and integrity. Backup systems, content-addressed stores and archive formats use it to answer “have I already got these exact bytes?”.

What a published SHA-256 looks like

Most of the time the value does not arrive on its own. A release page links a small text file — SHA256SUMS, sha256sum.txt, sometimes just CHECKSUMS — and inside it is one line per file, in a layout that has barely changed in thirty years: the digest, two spaces, then the name of the file it belongs to. This is what one looks like when you open it:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad  release-notes.txt
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  *installer.dmg

Three things to read off it before you compare anything. The first column is 64 characters wide, which names the algorithm before the filename does. An asterisk in front of a name means that file was read in binary mode, which on a Mac makes no difference to the digest — it belongs to the format, not to the value, and it must not come along when you copy the line. And you want the one line whose filename matches the file you downloaded: a list covering nine editions of a release has eight lines in it that are supposed to disagree with you, which is a more common cause of a failed check than corruption is. The anatomy of a checksum file goes through the format line by line, including the variants that put the filename first.

Comparing 64 characters without reading them

Producing the digest is the easy half. The half that goes wrong is the comparison, because nobody reads 64 characters — they read the first four, the last four, and trust the middle. Against accidental corruption that is a reasonable shortcut, since a damaged download has no way to preserve the ends. Against somebody who chose the bytes on purpose it is no check at all.

When the value arrived as text — a digest in an email, a line copied out of a SHA256SUMS file, a hash a colleague says ought to match yours — the box above will do the comparison for you. Switch to Check a checksum, paste the published value, and it is held against the digest of the text above, with the algorithm worked out from the length of what you pasted, so there is nothing to choose first. A whole SHA256SUMS line works as well as the bare 64 characters do, asterisk and filename included.

When what is being checked is a file, the comparison has to happen where the file is. In the Verify tool of Rocket Hash you paste the published value into Against a Checksum, drop the file beside it, and the answer arrives as a green seal and a sentence rather than two strings lined up for you to squint at; the algorithm is detected from the checksum itself, so there is nothing to pick from a menu first. The second mode, File vs. File, is the same idea without a published value: two drop wells with a swap control between them, and a verdict on whether the two copies are identical byte for byte. Verifying a SHA-256 checksum on a Mac walks it through with a real published value, and what to do when a checksum does not match is the page for the other outcome.

Hashing a file, on your Mac instead

A tab is the right shape for a string. It is the wrong shape for a file, and not in a way more JavaScript would fix: this page has no access to your disk, so the digest of a download, a disk image or a folder of photographs is not something it can hand you.

The Files tool is where that job lives. Folders arrive whole by drag-and-drop, each file becomes a row carrying its name, the folder it came from, its size and its digest, and a chevron on the row opens every algorithm for that file at once. The file is read exactly once however many digests you asked for, memory stays flat at roughly 16 MB whatever the file size, live throughput and an estimated time remaining run while it works with a summary and a progress count in the status bar along the bottom, and a long run can be paused mid-file and resumed from the exact byte it stopped at. What you are left with exports as a shasum-compatible manifest — digest, two spaces, filename, one line per file — which is the record to keep if the point is to check the same folder again next year. Hashing a file on a Mac is the short version of the route, and exporting a checksum manifest covers the file it leaves behind.