SHA3-256 hash generator

Two things bring people to this page. Either a specification says SHA3-256 and the tool in reach says SHA-256, which looks close enough and is not; or a digest produced by a library whose function was called sha3 refuses to match anything, which is a different problem with the same root cause. Both land in the same place: SHA-3 is not a version of SHA-2, and Keccak is not quite SHA-3.

A sponge instead of a chain

SHA-256 and SHA-512 are built the Merkle–Damgård way: a compression function, a running state, one block of the message folded in at a time, and at the end the state itself is handed to you as the digest. Every widely used hash from MD4 onward worked like that.

SHA-3 is a sponge wrapped around a single 1600-bit permutation called Keccak-f, which is run 24 rounds at a time. The 1600 bits are split in two. For SHA3-256, 1088 bits — 136 bytes — are the rate: the part your message is mixed into, a block at a time. The remaining 512 bits are the capacity, which the message never touches directly and which is never shown to you. Once the whole input has been absorbed, 256 bits are squeezed back out, and that is your 64 characters.

That shape has a consequence worth more than the length of the output. Because the digest is a small window onto a much larger hidden state, holding a SHA3-256 digest tells you nothing about the machine's internals — so you cannot resume the computation and append bytes to someone else's message, which is a trick that works against SHA-256 and SHA-512 and is the reason protocol designers reach for HMAC. SHA-3 needs no such wrapper. The capacity is also where its security level comes from: it is deliberately twice the output size.

The padding byte behind every Keccak mismatch

Keccak won NIST's hash competition in 2012. When it was standardized as FIPS 202 in 2015, NIST made one change to the submitted design: a domain-separation suffix appended to the message before padding, so that SHA-3 and the other functions built on the same permutation could never produce the same digest for the same input. In bytes, the first padding byte became 0x06 where the original Keccak used 0x01.

That is the entire difference. Same permutation, same rounds, same rate, same capacity, one byte of padding — and digests with no relationship at all. The original, pre-standard version is what Ethereum adopted and still uses everywhere it says keccak256, including in Solidity. The two are easy to tell apart if you know one value: Keccak-256 of an empty input is c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, against a7ffc6f8… for SHA3-256 above.

This page, and every SHA3 label on this site, means the standardized FIPS 202 function. Generating a SHA-3 hash on a Mac goes further into the Ethereum side of it, including what to do when a contract's digest and yours disagree.

Where SHA3-256 actually turns up

Honestly: not in download checksums. Linux ISOs, release archives, Homebrew and Git all speak SHA-256, and nothing macOS ships computes SHA-3 at all, at any width — which is its own quiet reason the format never caught on for published values, and the reason a SHA3-256 usually arrives from somewhere else and then sits there unchecked. Where it does appear:

• Specifications written after 2015. Newer protocol drafts, signature schemes and procurement profiles name SHA3-256 explicitly, usually because the authors wanted a hash from outside the SHA-2 family.
• The rest of the Keccak family. SHAKE128 and SHAKE256 produce output of any length you ask for, and KMAC is a keyed MAC — all from the same permutation. If your code needs a MAC and you already have SHA-3, KMAC saves you the HMAC construction entirely.
• Algorithm diversity on purpose. Some archives and manifests record a SHA-256 and a SHA3-256 side by side, so that a future weakness in one family leaves the other standing. It costs one extra column, and both digests can be computed in the same pass over the bytes.
• Hardware and embedded work. Keccak has no message schedule to build and gets more throughput per unit of silicon area than SHA-2, which was one of the reasons NIST chose it and is why it turns up in secure elements and firmware verification.

The case for keeping a second family around

SHA-3 was not commissioned because SHA-2 broke. It was commissioned because of how its predecessors broke. MD5 collisions went from theory to trivial in 2004, and SHA-1 collisions were demonstrated publicly in 2017 with two different PDF files that shared a digest — and both fell to the same broad technique, differential attacks against the compression-and-chain design they shared with SHA-2. NIST ran a competition to have something ready that would not fall to that technique, and a sponge over a permutation is about as structurally different as you can get while still being a hash function.

Two clarifications that get mangled constantly. First, what MD5 and SHA-1 lost was collision resistance — the difficulty of producing two different inputs that land on the same digest. Nobody can take an MD5 digest and reconstruct the file that produced it; preimage resistance survives in both. That distinction is why MD5 is still tolerable for spotting a corrupted transfer and useless for proving a file is the file you were promised.

Second, SHA-3 is not the stronger option today. SHA-256 and SHA3-256 both offer 128 bits of collision resistance, neither has been dented, and choosing the newer number is not an upgrade — it is a diversification. SHA-2 versus SHA-3 lays the two out side by side, and if nothing has specified anything, which algorithm to use gives the short answer, which is SHA-256.

SHA-3 on your Mac, outside a browser

Everything above happens in this tab, and it happens on text: type or paste a string and the 64 characters are recomputed as you go, with nothing uploaded — there is no endpoint to upload to, which you can confirm in your browser's network inspector. That covers what brings most people here, which is one 64-character value somebody sent them and one input to test it against. A file is a different job, and not one a page in a tab can do at all: reading bytes off your own disk is what an app on the Mac is for.

Rocket Hash lists SHA3-256 and SHA3-512 under their own SHA-3 heading, separated from the SHA-2 group so that you cannot copy the wrong 64-character digest by accident — which, given everything on this page, is the control that earns its keep. Each row is a labelled algorithm chip followed by the digest, long values shortened in the middle with an ellipsis, and clicking the row copies that one value in full: what lands on the clipboard is always the algorithm whose name you were reading. Text hashing is free.

The diversity case from further up the page is the one that needs an app rather than a page, because it starts with a file. In the Files tool a file is read exactly once and every algorithm you asked for comes out of that single pass, so recording a SHA-256 and a SHA3-256 for the same archive costs one trip through the bytes rather than two; the chevron on a file's row opens both values one under the other, with their names attached, and the finished list exports as a shasum-compatible manifest. And when a 64-character value somebody sent you refuses to match, having both digests on screen under their own headings is how you find out in one glance which of the two families they were using. Hashing a file on a Mac covers the route, and exporting a checksum manifest covers what you are left holding.

Frequently asked questions

Is a SHA3-256 hash the same length as a SHA-256 hash?

Yes — both are 256 bits, which is 64 hexadecimal characters, and that is exactly what makes the mix-up so easy. There is no way to tell from a 64-character value which of the two functions produced it, so a digest passed between systems should be labeled. If a comparison fails and both values are 64 characters, different algorithms is the first thing to check.

How do I get the SHA3-256 of a file instead of text?

Not on this page — a web page has no access to your disk, and this box hashes exactly the characters you type into it. For a file, a folder, or a download you are checking against a published value, that is the Files and Verify tools in the Mac app: a file is read once and every algorithm, SHA3-256 included, comes out of that single pass. Generating a SHA-3 hash on a Mac walks through it.

Why does my SHA3-256 not match what my library's sha3 function produced?

Because the library is probably computing original Keccak rather than standardized SHA-3. NIST added a domain-separation byte when it published FIPS 202 in 2015 — 0x06 where the competition version used 0x01 — and libraries written before that date shipped the old one under the SHA-3 name. Hash an empty string: SHA3-256 gives a7ffc6f8… and Keccak-256 gives c5d24601….

Is Ethereum's keccak256 a SHA-3 hash?

Not the standardized one. Ethereum froze on the competition version of Keccak before FIPS 202 was finalized, so keccak256 in Solidity and in every Ethereum library is the 0x01 padding variant. It is the same permutation with the same security properties, but the digests differ completely, and no amount of re-running SHA3-256 will reproduce one.

Does SHA3-256 need HMAC to be used with a key?

No. HMAC exists because SHA-2's digest is its own internal state, which lets somebody extend a message without knowing the secret. A sponge does not leak its state, so hashing a key followed by a message is safe with SHA-3 — and NIST specifies KMAC for exactly this, built on the same permutation. If a protocol you have to interoperate with specifies HMAC-SHA3-256, use that anyway; matching the other side is what matters.

Is SHA3-256 vulnerable to the attacks that broke SHA-1?

No, and neither is SHA-256 so far. The SHA-1 collision published in 2017 came from a differential attack on the compression-and-chain structure that SHA-1 shared with MD5 and, in outline, with SHA-2. SHA-3's sponge over a 1600-bit permutation is a different structure, which is precisely why NIST wanted it standing by. The best published attacks on Keccak reach only a fraction of its 24 rounds.

Does SHA-3 come in other sizes?

Yes: SHA3-224, SHA3-256, SHA3-384 and SHA3-512, plus SHAKE128 and SHAKE256, which will give you an output of any length you ask for. They all use the same Keccak permutation and differ in how much of the 1600-bit state is reserved as capacity — wider output means more capacity, less rate, and therefore more runs of the permutation to get through the same input.