SHA Hash & HMAC Generator

What a hash is

A cryptographic hash function takes any input — a single character, a paragraph, a 4 GB disk image — and produces a fixed-length string of bytes called a digest. The same input always yields the same digest, but flipping one bit of the input scrambles the whole output unpredictably (the avalanche effect). Two properties follow: the digest is a compact fingerprint of the data, and it is one-way — there is no operation that turns a digest back into the original input. That is why hashes are used to check that a file arrived intact, to index and de-duplicate content, and (with extra machinery) to store passwords.

Worked example: hashing the word "hello"

Type the five lowercase letters hello (no quotes, no newline) into the box above with SHA-256 selected and Hex output. You get exactly:

Those are stable, reproducible values — any correct SHA-256 implementation on Earth prints the same 64 hex characters for the input hello. Now change just the first letter to a capital H. The SHA-256 becomes 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969 — completely different, sharing no visible pattern with the first, even though only one bit of the input moved. Switch Output format to Base64 and the same SHA-256 of hello renders as LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=; it is the identical 32 bytes, just written in a different alphabet.

Algorithm reference

MD5 and the Secure Hash Algorithm (SHA) family differ mainly in output size and collision safety:

A collision is two different inputs with the same digest. For MD5 you can now generate one in seconds; SHA-1 fell in 2017 when Google's SHATTERED project published two distinct PDFs sharing one SHA-1 digest. So anything tamper-sensitive must use SHA-256 or larger. (This tool deliberately omits MD5 as a generator option to steer you away from it, but it is listed here because you will still meet MD5 checksums in the wild.) SHA-256 is the everyday standard; SHA-384 and SHA-512 add headroom and can actually be faster than SHA-256 on 64-bit machines because they compute in 64-bit words.

Verifying a download (step by step)

Suppose you download ubuntu-24.04.iso and the release page lists a SHA-256 checksum (often in a file called SHA256SUMS). Switch this tool to File mode, drop the ISO in, keep SHA-256 selected, and paste the published checksum into the Compare against an expected checksum field under the results — no squinting at 64 characters by eye. The field is deliberately forgiving about formatting: 2CF24DBA…, 2c:f2:4d:ba:… and a whole SHA256: 2cf24dba… or sha256sum output line all normalize to the same digest before comparing. A green MATCH means the file is byte-identical to what the publisher released — no corruption in transit and no injected malware. A red MISMATCH means discard it. Pasting something that is not hex at all is flagged as invalid rather than counted as a failed match, and a digest of the wrong length gets a hint (40 hex characters looks like SHA-1, not SHA-256). This is the same integrity check a package manager runs automatically; doing it by hand is worth the minute for installers, firmware, VM images and anything you will grant system permissions to.

CRC-32: a checksum, not a hash

The CRC-32 option computes a cyclic redundancy check — the exact 32-bit variant embedded in every ZIP entry, gzip stream, PNG chunk and Ethernet frame (formally CRC-32/ISO-HDLC: polynomial 0x04C11DB7 processed bit-reflected, initial value and final XOR both 0xFFFFFFFF). Its job is narrow: detect accidental damage. It is guaranteed to catch any single-bit flip and any error burst up to 32 bits long, which is why file formats and network links use it as a cheap tripwire. The canonical self-test: type 123456789 above with CRC-32 selected and you get cbf43926 — the published check value every correct implementation must produce.

What CRC-32 is not is any kind of security. It is a linear function, so collisions are not just findable, they are constructible: appending four calculated bytes to any file forces the CRC to any chosen value, a microseconds-of-arithmetic trick, no brute force involved. With only 2³² possible values, random collisions also appear after roughly 77,000 files (the birthday bound) — compare that to SHA-256, where no collision has ever been found. So use CRC-32 to answer "did this byte stream survive the trip intact?" when you already trust the sender — matching a ZIP tool's reported CRC, checking a serial-link transfer, debugging a PNG encoder. Never use it to decide whether a download was tampered with; that question needs SHA-256. Unlike the SHA path (which uses the browser's Web Crypto engine), CRC-32 here is a small table-driven pure-JavaScript routine, and in File mode it streams the file in 4 MB slices, so a multi-gigabyte disk image checksums without freezing the tab or loading fully into memory.

HMAC: hashing with a secret key

A plain digest answers "did these bytes change?" — but anyone can recompute it, so it cannot answer "did you send this?". HMAC (Hash-based Message Authentication Code, RFC 2104) folds a shared secret key into the hash, so the tag can only be produced or verified by someone who holds the key. That gives you integrity and authenticity in one value. Switch to the HMAC tab above, type a message and a key, and you get HMAC-SHA256(key, message) live.

The key encoding matters. A passphrase you typed is UTF-8 text; a random 256-bit key handed to you by an API is almost always hex (64 characters) or Base64, and decoding it wrong gives a completely different, silently-wrong tag — the number-one HMAC bug. This tool makes the encoding explicit and flags a malformed hex or Base64 key inline instead of hashing garbage. You can verify it against a published vector: HMAC-SHA256 of Hi There with a key of twenty 0x0b bytes (enter 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b with key encoding set to Hex) is b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7 — that is test case 1 of RFC 4231, and any correct HMAC implementation prints the same 64 characters.

Where you meet it: webhook signatures (Stripe's Stripe-Signature, GitHub's X-Hub-Signature-256 and Shopify all sign the raw request body with HMAC-SHA256, and you re-compute the tag with your endpoint secret to reject forgeries), signed API requests (AWS Signature v4 chains several HMAC-SHA256 steps), and tamper-evident cookies or tokens. One honest caution: HMAC authenticates a message with a shared secret — it is not a public-key signature (both sides hold the same key, so either side could have produced the tag), and it is not a password-storage function. When you compare a received tag against your computed one in real code, use a constant-time comparison so timing does not leak the secret.

Common mistakes

• Hashing is not encryption. Encryption is reversible with a key; hashing is one-way and keyless. A site that offers to "decrypt" a hash is really looking the value up in a table of pre-computed common inputs — that only works for short, guessable strings, never for high-entropy data.
• Don't store passwords with a plain SHA. SHA functions are built to be fast, which is exactly wrong for passwords: an attacker with a leaked table can try billions of guesses per second. Password storage needs a deliberately slow, salted function — bcrypt, scrypt or Argon2.
• Watch hidden bytes. A trailing newline, a UTF-8 BOM, or CRLF vs LF line endings change the input, so they change the digest. If two hashes of "the same" text disagree, the bytes were not actually the same.
• Case and format are cosmetic, not the value. Uppercase vs lowercase hex, or Hex vs Base64, are two spellings of the identical bytes; compare like with like before deciding a checksum failed.

Honest limits

Everything here runs locally through crypto.subtle.digest, the browser's own audited Web Crypto implementation, so your text and files never leave the tab — open your network panel and you will see zero requests. Because it uses that API, it offers only the hash algorithms browsers ship (SHA-1/256/384/512), as a plain digest or a keyed HMAC; it does not compute MD5 or newer SHA-3/BLAKE hashes. (CRC-32 is different: it is a checksum, not a hash, and is computed by a small pure-JavaScript routine on this page.) It hashes the raw bytes you supply and does not normalise Unicode, trim whitespace, or strip byte-order marks for you. Very large files are read into memory for the SHA digests, so multi-gigabyte inputs depend on your device's RAM — only the CRC-32 path streams in slices. For huge files, a command-line tool like sha256sum that streams is the better fit.

Want the concepts, not just the tool? Learn more in our guide, Hashing Explained → — what a one-way digest is, the avalanche effect, why hashing is not encryption, and why passwords need a salted, slow KDF rather than a plain SHA.