SHA256 Hash Generator, File Checksum & Hash Identifier

Compute and identify SHA-1/256/384/512, HMAC, and MD5 hashes, verify file checksums, and test password strength.

Hash Lab computes MD5, SHA-1, SHA-256, SHA-384 and SHA-512 digests for text or files, signs and verifies HMACs, guesses which algorithm produced a pasted hash from its length, and runs a dictionary attack against a target hash — every operation client-side, with a persistent warning attached to the two algorithms that shouldn't be trusted for security purposes anymore.

How to verify a file checksum

  1. Open the Verify a file checksum panel and pick the algorithm the publisher lists next to the download. SHA-256 is preselected; MD5, SHA-1, SHA-384 and SHA-512 are in the same menu.
  2. Drop the file onto the panel or click to choose it. The whole file is read into memory and hashed in the tab, so a very large file needs that much free RAM.
  3. Paste the published checksum into Expected checksum. Surrounding spaces are trimmed, and upper- or lowercase hex both compare correctly.
  4. Read the verdict. Match means the bytes are identical to what the publisher hashed; Mismatch means a corrupted or tampered download, the wrong file, or the wrong algorithm. Switching the algorithm re-hashes the same file.

Where each hash actually gets computed

SHA-1, SHA-256, SHA-384 and SHA-512 all run through the browser's native SubtleCrypto digest function — fast, standard, no JavaScript reimplementation of the compression function involved. MD5 is the exception, because SubtleCrypto has no MD5 implementation at all: hashing text uses the widely-used blueimp-md5 package, while hashing a file's raw bytes uses a separate, hand-written RFC 1321 MD5 core that operates directly on bytes.

That split exists for a specific, verified reason: blueimp-md5's text-hashing function always UTF-8-encodes its input first, which is exactly correct for hashing a string of text, but is wrong for a file's raw binary content — feeding it a byte-per-character string re-encodes any byte at or above 0x80 into a different multi-byte sequence, silently producing a checksum that won't match the file's real MD5. That divergence was verified against Node's own MD5 implementation for every byte value 0 through 255 while building this tool, which is why file checksums route through the separate byte-exact implementation instead.

Hash lengths at a glance, with the digests of "abc"

Each algorithm always prints the same number of hex characters, however large the input, and that fixed length is all the identifier goes on. Below are the digests of the three-letter text abc with no trailing newline, which you can reproduce in the Compute a digest panel.

Only these five lengths are recognised. A bcrypt string ($2b$…), a crypt-style $1$ hash or a Base64-encoded digest returns no match, and a SHA3-256 or BLAKE2s digest, also 64 hex characters, will still be labelled SHA-256.

Why your hash doesn't match another tool

A correct SHA-256 implementation gives the same digest for the same bytes everywhere. When two tools disagree, the bytes going in were different.

HMAC signing and verification

HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 are both available for signing a message under a key and for verifying a signature against a message and key — again through native SubtleCrypto rather than a hand-rolled implementation. Verification never throws on a malformed signature; a hex string that doesn't parse correctly just returns false, which matters for building a UI that gives a clean yes-or-no answer instead of an unhandled error.

Identifying a hash and attacking it

Pasting a bare hex string into the identifier checks its length and character set against the five supported algorithms — MD5, SHA-1 and each SHA-2 variant all produce a fixed, distinct output length in hex, so the match is unambiguous when there is one, and returns nothing when the input isn't valid hex or doesn't match any known length.

The dictionary attack demo hashes every entry from a bundled list of roughly common passwords under your chosen algorithm and compares each result to a target hash you provide, reporting progress as it goes and stopping the moment it finds a match. It can be cancelled mid-run, and it will never find a password that isn't in its bundled wordlist — this is a demonstration of why weak, common passwords are dangerous against fast hashes, not a general-purpose cracking tool.

Why MD5 and SHA-1 carry a persistent warning

Questions people ask about Hash Lab & Identifier

Is it safe to store passwords with SHA-256 through this tool?
No. SHA-256 itself, run once, is far too fast for password storage — modern hardware can try billions of guesses per second against it, which is exactly what makes the dictionary attack in this same tool work so quickly against weak passwords. Real password storage needs a deliberately slow function like bcrypt, scrypt or Argon2, none of which this tool implements.
Why does file hashing use a different MD5 implementation than text hashing?
The text-hashing library always converts its input to UTF-8 bytes first, which is correct for a text string but corrupts a file's raw binary content — any byte at or above 0x80 gets re-encoded into something different, silently producing the wrong checksum. File hashing instead uses a separate, hand-written MD5 implementation that operates directly on the file's actual bytes with no text-encoding step.
Does the dictionary attack try every possible password, or just a list?
Just a bundled wordlist of roughly common passwords — it hashes each entry under the algorithm you pick and compares it against your target hash, stopping on the first match. It cannot find a password outside that list; it's a demonstration of why weak, guessable passwords are vulnerable against fast hash functions, not an exhaustive brute-force cracker.
Can hash identification tell me for certain which algorithm produced an unknown hash?
It narrows things down by length and hex character set, and since MD5, SHA-1 and the three SHA-2 variants each produce a different fixed output length, a valid hex string of the right length matches at most one of the five supported algorithms. It can't confirm the guess is correct without the original input to re-hash and compare, though.
Can a SHA-256 hash be decrypted or reversed?
No. Hashing is not encryption: there is no key and no inverse function. What gets called reversing is guessing, hashing candidate inputs until one produces the same digest. The dictionary-attack panel shows exactly that, and it only succeeds when the original input was short or common.
How do I verify a downloaded file's checksum?
Choose the algorithm the publisher names, drop the file into Verify a file checksum and paste their published value; the panel answers Match or Mismatch. On a mismatch, download again. For security-sensitive software, also make sure the checksum itself came from the publisher's own HTTPS page.
Why is my hash different from another tool's output?
Almost always because the input bytes differ rather than the algorithm: a newline added by echo, extra spaces, CRLF line endings, or text hashed as UTF-16 instead of UTF-8. Feed both tools identical bytes and every correct SHA-256 implementation returns the same 64-character digest.
What is HMAC-SHA256?
HMAC hashes a message together with a secret key, so only someone who holds the key can produce or check the result. APIs and webhooks use HMAC-SHA256 signatures to prove a request was not altered in transit. Hash Lab signs and verifies HMAC-SHA-256, -384 and -512 with a text key and hex output.
Is my file uploaded when I hash it?
No. The browser reads the file into memory and hashes it on the page, with Web Crypto for the SHA family and a built-in MD5 routine for MD5. No request carries the file or its checksum anywhere, so hashing a confidential archive or disk image here is fine.

Related tools on BrakeTools

Content reviewed 2026-09-27.