SHA-3 / Keccak Hash Generator & Verifier

Generate and verify SHA-3 and Keccak hashes in all four lengths (224/256/384/512) and see exactly why SHA3-256 and Keccak-256 differ. Hashes text or multi-gigabyte files entirely in your browser, supports UTF-8/UTF-16/Latin-1/Windows-1252 and hex/base64 input, HMAC, and hex or base64 output.

SHA3-256 and Keccak-256 are different hashes

They share the same Keccak-f[1600] permutation, but NIST added two domain-separation bits when it standardised SHA-3 in FIPS 202 (padding suffix 0x06 instead of 0x01), so the digests never match. Ethereum — addresses, function selectors, keccak256() in Solidity, transaction and block hashes — uses Keccak-256, not SHA3-256, even though older docs and libraries call it "SHA3". Pick the family that matches your source before you compare anything.

Runs entirely in your browser. Browsers have no native SHA-3, so text and files are hashed by a WebAssembly module served from this site — no CDN script, nothing uploaded, nothing logged. Verify it yourself: open DevTools → Network, hash a 2 GB file, and watch zero requests appear after the one-time wasm fetch.

SHA3-256 digest

0 bytes hashed — canonical empty-input digest

Fix the input above to see a digest.

Input

The SHA-256-strength SHA-3 variant; rate 1088 bits. Output: 256 bits = 64 hex characters.

0 characters · 0 encoded bytes

UTF-8 is what Solidity's keccak256(bytes) sees for a string literal, and what sha3sum and every modern web API use.

Compare against an expected hash

Paste the expected digest — bare hex (with or without an 0x prefix is fine on the input side), base64, an sha3sum line (hash filename) or a BSD SHA3-256 (file) = hash tag.

The verdict appears as soon as both a digest and an expected hash exist. Works for text and files. A mismatch on a 64-character digest is very often a SHA3-256 / Keccak-256 mix-up rather than a corrupted file.

All eight variants

Compute SHA3-224, SHA3-256, SHA3-384, SHA3-512 and all four Keccak variants of the same input, each labelled with its Hashcat mode — the fastest way to work out which variant produced a digest you were given.

SHA-3 is not a password hash either

SHA-3 and Keccak are fast, unkeyed, memory-cheap functions — everything you do not want when storing a password. Being newer than SHA-2 does not change that. Use a deliberately slow, memory-hard function: Argon2id, bcrypt (cost ≥ 12), scrypt or PBKDF2. SHA-3 belongs in signatures, commitments, Merkle trees and content addressing.

Why two tools disagree about "the" SHA-3 of your text

  • • SHA-3 vs Keccak. The most common cause by far. A library called "sha3" from before 2015 — including Ethereum's — usually computes Keccak.
  • • A trailing newline. echo "abc" | sha3sum -a 256 hashes 4 bytes, not 3. Use echo -n or the toggle above.
  • • Text vs bytes. Solidity's keccak256(abi.encodePacked(x)) hashes packed binary, not the hex string you see in a block explorer — select "Hex bytes" to reproduce it.
  • • A BOM or a different encoding. "café" is 5 bytes in UTF-8, 4 in Latin-1 and 8 in UTF-16 — three different digests for the same visible text.
  • • Variant length. SHA3-512 truncated to 64 hex characters is not SHA3-256; each variant uses a different sponge capacity.

Technical specifications

  • • Construction: sponge over the Keccak-f[1600] permutation, 24 rounds — not Merkle–Damgård, so SHA-3 and Keccak are immune to length-extension attacks
  • • SHA-3 (FIPS 202, 2015): padding suffix 0x06 (domain-separation bits 01 + pad10*1), Hashcat modes 17300–17600
  • • Keccak (original 2012 submission): padding suffix 0x01, Hashcat modes 17700–18000
  • • Rate / capacity: 1600 − 2n bits of rate for an n-bit digest (1088/512 for the 256-bit variants), giving n/2-bit collision resistance
  • • Current variant: SHA3-256, 256 bits = 32 bytes = 64 hex characters
  • • Empty input: SHA3-256 of zero bytes is a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a
  • • Engine: hash-wasm WebAssembly (no browser exposes SHA-3 through the Web Crypto API), 4 MiB streaming chunks for files
  • • Not covered here: SHAKE128/SHAKE256 are extendable-output functions (arbitrary-length output), not fixed-length hashes, and cSHAKE/KMAC build on them
  • • Verification: hex compared case-insensitively, base64 compared case-sensitively (base64 is a case-significant alphabet)

Common use cases

Ethereum and EVM chains: Keccak-256 for addresses, the 4-byte function selector (first 4 bytes of the signature hash), storage slots, event topics and EIP-712 digests.
Algorithm diversity: SHA-3 as a structurally different backup to SHA-2 in protocols that want to survive a break of the Merkle–Damgård family.
Length-extension-safe MACs: because the sponge absorbs the key safely, SHA3(key ‖ message) and KMAC are secure constructions where SHA-256(key ‖ message) is not.
Post-quantum signatures: SHA3/SHAKE are the hash primitives inside ML-DSA (Dilithium) and SLH-DSA (SPHINCS+).
Commitments and Merkle trees: content addressing where the sponge construction simplifies the security proof.
Identifying an unknown digest: 64 hex characters could be SHA-256, SHA3-256, Keccak-256, BLAKE2s or BLAKE3 — Hash Identifier ranks the candidates and shows each Hashcat mode.

About SHA-3 / Keccak Hash Generator & Verifier

The SHA-3 / Keccak Hash Generator & Verifier computes all eight fixed-length sponge digests — SHA3-224, SHA3-256, SHA3-384, SHA3-512 and Keccak-224, Keccak-256, Keccak-384, Keccak-512 — from text or files, and verifies them against a hash you already have. Each variant is labelled with its Hashcat mode (17300–17600 for SHA-3, 17700–18000 for Keccak) so an unknown digest can be matched to the function that produced it. Text is hashed live as you type and files are streamed through WebAssembly in 4 MiB chunks; input can be read as UTF-8, UTF-16LE/BE, ISO-8859-1, Windows-1252, or raw hex/base64 bytes.

Why use a SHA-3 / Keccak Hash Generator & Verifier?

The single most expensive mistake in this corner of cryptography is treating SHA3-256 and Keccak-256 as the same function. They use the same permutation but different padding, so their digests never match — and Ethereum uses Keccak-256 while calling it 'SHA3' in older documentation. This tool keeps both families selectable, computes all eight variants of the same input side by side so the difference is visible, and runs entirely on a local WebAssembly module rather than a script pulled from a third-party CDN. It also gets the details other tools miss: no silent UTF-16 BOM, empty input allowed, and case-sensitive base64 comparison.

Who is it for?

Solidity and EVM developers computing addresses, function selectors, storage slots and EIP-712 digests; blockchain integrators debugging why their library's 'sha3' disagrees with a block explorer; protocol designers adopting SHA-3 for algorithm diversity or length-extension immunity; and anyone holding a 64-character digest that SHA-256 does not explain.

How to use the tool

1

Choose Hash Text to hash typed input, or Hash File to checksum a file from disk.

2

Pick the variant: SHA3-224/256/384/512 for NIST FIPS 202, or Keccak-224/256/384/512 for the original padding — each option shows its Hashcat mode.

3

For anything Ethereum-related (addresses, keccak256() in Solidity, function selectors, event topics) select Keccak-256, not SHA3-256.

4

Type or paste your input — the digest updates live above the input box, and an empty box shows the canonical empty-input digest for the selected variant.

5

Pick the input encoding: UTF-8 for string literals, or 'Hex bytes' to hash ABI-encoded calldata and raw transactions the way on-chain tooling does.

6

Tick 'Append a trailing newline' when reproducing echo "text" | sha3sum -a 256, which hashes an extra LF byte that echo -n does not add; leave 'Prepend a BOM' off to match command-line tools.

7

In file mode, drop a file onto the drop zone — the progress bar shows percentage and MB/s while the file streams through the selected variant, and changing the variant re-hashes the same file.

8

Paste the expected digest into 'Compare against an expected hash' for a green match / red mismatch verdict, then open 'All eight variants' to see which variant actually produced it.

Frequently Asked Questions

How do I generate a SHA-3 or Keccak hash of text or a file?

Select the variant (SHA3-256 is the default; pick Keccak-256 for Ethereum), then type into the input box — the digest appears immediately and updates on every keystroke. Choose an input encoding first if your source is not UTF-8; 'Hex bytes' is what you want for ABI-encoded calldata. In file mode, drop a file onto the drop zone: it is read in 4 MiB chunks and fed through a streaming sponge implementation, so nothing is uploaded and nothing is held in memory in one piece. Results match sha3sum -a 256, openssl dgst -sha3-256 and rhash on the same bytes.

What is the difference between SHA3-256 and Keccak-256?

Only the padding — but that is enough to produce completely different digests. Both use the Keccak-f[1600] permutation with a 1088-bit rate, but when NIST standardised SHA-3 in FIPS 202 (2015) it appended two domain-separation bits before the pad10*1 rule, giving padding suffix 0x06 instead of Keccak's 0x01. SHA3-256("") is a7ffc6f8bf1ed766… while Keccak-256("") is c5d2460186f7233c…. Ethereum froze on the pre-standard version, so addresses, Solidity's keccak256(), function selectors and block hashes are all Keccak-256 — even where the documentation says 'SHA3'.

Is it safe to hash sensitive data in this tool?

Yes. The tool runs entirely in your browser. Browsers expose no native SHA-3, so text and files are hashed by a WebAssembly module served from this site — not by a script fetched from a third-party CDN, and not by a server. Your input never leaves the page, is never logged and is never stored. Verify it without trusting us: open DevTools, switch to the Network tab, hash a large file and watch zero requests appear after the one-time WebAssembly fetch. That matters here, because seed phrases and private-key material are exactly the kind of input people paste into a Keccak tool.

SHA-3 vs SHA-256 — which should I use in 2026?

SHA-256 remains the default: universally supported, hardware-accelerated, and specified by TLS, code signing, Git and most protocols. Choose SHA-3 when you want structural diversity from the SHA-2 family, when you need immunity to length-extension attacks (the sponge makes SHA3(key ‖ message) a safe MAC, which SHA-256 is not), or when a spec names it — post-quantum signatures such as ML-DSA and SLH-DSA build on SHA3/SHAKE. What you should not use for anything security-relevant is [MD5](/tools/md5-hash-generator-verifier/) or [SHA-1](/tools/sha1-hash-generator-verifier/): both are collision-broken.

What is the SHA3-256 hash of an empty string?

a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a. Keccak-256 of the empty string is different: c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 — a value worth memorising, because Ethereum uses it as the hash of empty contract code and it appears throughout state tries. Both are digests of zero bytes, so they are also the checksums of every empty file. The tool allows empty input deliberately and labels the result; many online hash tools block it, which hides one of the most useful reference values in the whole family.

How do I verify a file's SHA-3 checksum?

Switch to Hash File, choose the variant the publisher used, drop the file in, and paste their checksum into the compare box — a bare digest, an sha3sum line (hash, two spaces, filename) or a BSD SHA3-256 (file) = hash tag all work. Hex is compared case-insensitively and base64 case-sensitively. If a 64-character digest does not match, switch the variant between SHA3-256 and Keccak-256 before assuming the file is corrupt: that mix-up causes far more failed verifications than damaged downloads do. Changing the variant re-hashes the loaded file automatically.

Why doesn't my hash match another tool's output?

Four usual suspects, in order of frequency. First, SHA-3 versus Keccak — any library called 'sha3' from before 2015, Ethereum's included, usually computes Keccak. Second, a byte-order mark: many online tools silently prepend FF FE to UTF-16 input, and those two extra bytes change everything (SHA3-256 of "abc" as UTF-16LE is a7fc119e08d5dbcd… without a BOM and 8c530254c2e2627f… with one). Third, a trailing newline — echo "abc" | sha3sum -a 256 hashes 4 bytes, not 3. Fourth, hashing a hex string as text instead of decoding it to bytes first.

Can SHA-3 be used with a secret key (HMAC or KMAC)?

Yes — switch on 'Keyed mode' to compute HMAC over the selected variant. HMAC (RFC 2104) is defined for any hash and is what you need when a counterpart expects HMAC-SHA3-256. For new designs, though, the sponge offers something simpler: because SHA-3 is not vulnerable to length extension, SHA3(key ‖ message) is already a secure MAC, and NIST's KMAC (SP 800-185) formalises that with proper domain separation and no nested-hash overhead. Use a random key of at least 32 bytes and compare tags in constant time. See also the [HMAC Generator & Verifier](/tools/hmac-generator-verifier/).

Share This Tool

Found this tool helpful? Share it with others who might benefit from it!

💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.

Support This Project

Buy Me a Coffee