Hash Generator

A hash function takes any input and produces a fixed-length fingerprint of it. The same input always gives the same output, a one-character change gives a completely different output, and there is no way to work backwards from the hash to the original.

This tool computes SHA-1, SHA-256, SHA-384 and SHA-512 — for text as you type, or for a file you pick from your device. It also signs a message with a secret key using HMAC, which is the construction behind webhook signatures and API request signing.

Everything runs on the Web Crypto API built into your browser. A file is read in this tab and hashed here; it is never uploaded, which is rather the point when the thing you are verifying is a download you do not yet trust.

Pick the file in the file tab. It is read in chunks with a progress bar, then hashed with all four algorithms at once, so it does not matter which one the publisher chose to print. A 128 MB file takes about a second on a normal laptop.

Then paste the published checksum into the compare box. You do not have to clean it up first: a whole line of sha256sum output with the filename after it, a BSD-style “SHA256 (file) = …”, the space-separated hex certutil prints on Windows, or an sha384-… subresource integrity string are all understood, and the tool tells you which of the four digests the value matched.

This matters more than it looks. Comparing two 64-character strings by eye reliably degrades into checking the first four characters and the last four, which is exactly the comparison an attacker who can choose their own bytes would be delighted by. A machine comparison is either a match or it is not.

The limit is 128 MB, because the browser has to hold the whole file in memory to hash it. Beyond that, sha256sum on Linux and macOS or certutil -hashfile on Windows will stream it from disk and cost nothing.

HMAC proves who produced a message as well as that it has not changed. Sender and receiver share a secret key; the sender hashes the message with the key, and the receiver recomputes the same value. If they agree, the message came from someone holding the key. This is what the X-Hub-Signature and Stripe-Signature headers on a webhook contain.

The obvious homemade version — hash the secret concatenated with the message — is broken. SHA-1, SHA-256 and SHA-512 are Merkle-Damgård constructions, and their internal state is exactly what they output, so anyone holding a valid hash(secret + message) can append data and compute a valid signature for the longer message without ever knowing the secret. HMAC's nested inner and outer keying exists specifically to close that off.

The key can be entered as text or as hex here, because both forms are in circulation: webhook secrets are usually printable strings, while keys from a specification or a test vector are printed as bytes. The implementation is the platform's own and matches the RFC 4231 test vectors exactly.

One caveat when you verify a signature by hand: compare the whole value, and in production compare it in constant time. An ordinary string comparison returns as soon as it finds a difference, and the time it took is a measurable clue to how much of the signature was right.

SHA-256 for anything new. It is the default across the industry, it is fast enough for any practical purpose, and there is no known attack against it.

SHA-384 and SHA-512 produce longer digests. On 64-bit hardware SHA-512 is often faster than SHA-256 despite the longer output, so the choice between them is usually dictated by whatever specification you are implementing rather than by security.

SHA-1 is included for one reason: verifying legacy checksums and git object IDs that already exist. It is broken — practical collision attacks have been demonstrated — and it should not be used for anything where an attacker could benefit from forging a match.

Hashing is not encryption and has no inverse. A 512-bit digest is the same length whether the input was one character or a gigabyte, so information is unavoidably discarded on the way through.

Sites offering to reverse a hash are looking it up in a table of precomputed common inputs. That works for password, 123456 and every word in a dictionary. It does not work for anything with real entropy, which is exactly why a random password stays safe in a leaked database and a memorable one does not.