What is HMAC and when do I need it?

HMAC combines a hash with a secret key to prove a message came from someone holding that key and was not altered. A plain hash proves neither, because anyone can recompute it. HMAC is what signs webhook payloads and API requests. Switch to HMAC mode and supply the key.

Not for security. MD5 has practical collision attacks and must never be used for passwords, signatures or integrity against a motivated attacker. It is still perfectly reasonable for non-adversarial uses such as checksums, cache keys and ETags, which is why it is included here.

How should I hash passwords then?

Not with any of these. Password storage needs a slow, salted algorithm designed for the job, such as bcrypt, scrypt or Argon2. A fast general-purpose hash like SHA-256 can be brute-forced at billions of guesses per second.

Is my input sent to a server?

No. SHA hashing uses the browser Web Crypto API and MD5 is implemented in JavaScript on the page, so your text never leaves your device.

Why is MD5 not in the browser Web Crypto API?

It was deliberately left out because it is cryptographically broken, so it is implemented separately here. The implementation is verified against the official RFC 1321 test vectors.

Does it handle non-English text?

Yes. Input is encoded as UTF-8 before hashing, so Japanese, Chinese, Korean and emoji produce the same hashes you would get from any standard command-line tool.

Hash & HMAC Generator

Uppercase

Input

MD5insecure
SHA-1insecure
SHA-256
SHA-512

MD5 and SHA-1 are broken and must not be used for passwords or signatures. They remain fine for checksums and cache keys.

Nothing you enter here is stored, logged or shared.

Type or paste text to see its MD5, SHA-1, SHA-256 and SHA-512 hashes at once, or switch to HMAC to sign it with a secret key. Everything runs in your browser, so neither your text nor your key leaves your device.

How to use

Paste your text into the input field.
All four hashes are calculated as you type.
Copy any hash with the button beside it.

What a hash guarantees

A cryptographic hash maps input of any length to a fixed-size digest, deterministically: the same bytes always give the same result, and one changed bit changes roughly half the output. Three properties are what make it useful, and different uses need different ones.

Preimage resistance means that given a digest you cannot find an input producing it. Second-preimage resistance means that given one input you cannot find a different input with the same digest. Collision resistance means you cannot find any two inputs that collide, and it is the weakest of the three to attack, because the attacker gets to choose both sides.

That last distinction is why a broken algorithm is not equally broken for every purpose. MD5 collisions can be produced in seconds, but nobody can invert an MD5 digest, so MD5 as a cache key or a non-adversarial checksum is fine while MD5 as a signature is not.

The state of each algorithm

MD5 has been considered broken since 2004, and chosen-prefix collisions - where an attacker crafts two meaningfully different documents that hash identically - are now cheap. It was used to forge a working certificate authority in 2008 and by the Flame malware in 2012. Use it for checksums, ETags and cache keys; never for anything an adversary would benefit from subverting.

SHA-1 followed. The first practical collision was demonstrated in 2017 with two PDFs, and a chosen-prefix collision landed in 2020 at a cost of tens of thousands of dollars. Browsers stopped accepting SHA-1 certificates years ago and Git has been migrating away from it. Treat it as MD5 with a longer lifespan.

SHA-256 and SHA-512 are the current defaults and have no known practical weaknesses. Both are in the same SHA-2 family; SHA-512 is often faster on 64-bit hardware despite the longer output. SHA-3 exists as a structurally different backup rather than a replacement, and BLAKE3 is worth knowing about where speed on large files matters.

HMAC, and why not just hash the key with the message

A plain hash proves nothing about who produced it, since anyone can compute one. HMAC adds a secret key, so a matching digest shows the sender knew the key and the message has not been altered. This is what signs webhook deliveries from Stripe, GitHub and everyone else, and what authenticates AWS API requests.

The intuitive construction - hash the key followed by the message - is broken for the SHA-2 family, because those are Merkle-Damgard functions and their digest is their entire internal state. An attacker who has one valid digest can resume from that state and append data, producing a valid digest for a longer message without ever knowing the key. HMAC's nested structure, hashing twice with two derived keys, is what prevents it.

One thing to get right when verifying: compare digests in constant time. A normal string comparison returns as soon as it finds a difference, and the timing difference is measurable over enough requests, which lets an attacker recover a signature byte by byte. Most languages provide a dedicated function for this.

Hashing is not encryption, and not password storage

Hashing is one-way and has no key: there is nothing to decrypt and no way to recover the input. If you need the data back, you want encryption, which is a different tool entirely.

For passwords, a fast hash is precisely the wrong choice. Speed is the attacker's advantage: consumer hardware tries billions of SHA-256 guesses per second against a stolen database, and unsalted digests can be looked up in precomputed tables outright. Password storage needs a function that is deliberately slow and memory-hard, with a per-password salt - bcrypt, scrypt, or Argon2id, which is the current recommendation.

There is a subtler misuse worth naming: hashing an identifier to anonymise it. Hashing email addresses or phone numbers protects nothing, because the space of possible inputs is small enough to enumerate. Anyone with the digest can hash every address they hold and match. A hash of a low-entropy value is a lookup key, not an anonymisation.

Verifying a download, step by step

A published checksum answers one question: did the bytes I received match the bytes the publisher had. Hash the file locally - shasum -a 256 file.iso on macOS, sha256sum on Linux, Get-FileHash in PowerShell - and compare the digest with the one on the download page. A single differing character means the file is not the same file.

What that comparison does not tell you is whether the publisher's page was genuine. If an attacker can change the download, they can usually change the checksum next to it, which is why serious projects sign the checksum file with a GPG key rather than only publishing the digest. Verifying the signature and then the checksum is the chain that actually proves something.

This is also the reason MD5 is still acceptable for a checksum in a non-adversarial setting and unacceptable for a signature. Against a corrupted download MD5 works fine; against someone who wants two files to have the same digest, it has been broken since 2004.

Hashes as addresses, not just as checks

A large part of modern infrastructure identifies content by its hash rather than by a name. Git names every object by the digest of its contents, which is why a commit identifier is stable, tamper-evident and independent of where the repository lives. Container image digests work the same way, as do package lock files, which pin a dependency to exact bytes rather than to a version number someone could republish.

Deduplication uses the same idea: a backup system that hashes each block stores identical blocks once, and a content delivery network can cache by digest with no risk of serving stale data, because different content has a different address.

Merkle trees extend it. Hashing pairs of hashes upward produces a single root digest that commits to a whole dataset, which is what lets a client verify one item belongs to it without downloading everything. Certificate transparency logs, blockchains and several replicated databases all lean on that structure.

Verifying a webhook signature correctly

The pattern is the same across Stripe, GitHub, Slack and most others. The sender computes an HMAC of the raw request body with a shared secret and puts the digest in a header; the receiver recomputes it and compares. Four details decide whether the implementation is sound.

First, hash the raw body, not a re-serialised version of the parsed JSON - key order and whitespace change the bytes and therefore the digest. Second, compare in constant time, because a normal string comparison leaks where the first difference is and enough requests turn that timing into the signature. Third, include the timestamp the sender provides in the signed payload and reject anything older than a few minutes, or a captured request can be replayed indefinitely.

Fourth, support two secrets at once. Rotation is impossible if the receiver only knows one, and the usual approach is to accept either during a short overlap window.

Choosing parameters for password hashing

Argon2id is the current recommendation, and unlike a plain hash it takes parameters: memory, iterations and parallelism. The memory cost is what defeats specialised hardware, since GPUs and ASICs have far more compute than they have fast memory per core. A common starting point is 19 MiB with two iterations, and higher where the hardware allows.

The way to tune is empirical. Measure on the machine that will run it and choose the highest cost that keeps a login under roughly a quarter of a second, remembering that a login spike multiplies that cost across every concurrent request. bcrypt with a work factor of 12 remains acceptable and is easier to deploy in some stacks; scrypt sits between the two.

Migration does not require anyone's password. Store the algorithm and parameters alongside each digest, verify with whatever the stored record says, and rehash with the new settings at the moment of a successful login. Over a few months most active accounts move across on their own.

Where hashes are the wrong tool

Hashing an identifier to anonymise it does not work, and the reason is worth understanding rather than memorising. A hash is deterministic and the input space is small: there are only so many email addresses and phone numbers, so anyone holding the digests can hash every candidate they have and match. Several advertising and analytics schemes marketed as privacy-preserving rest on exactly this mistake.

Where you genuinely need to compare identifiers without revealing them, the primitives are different - keyed hashes with a secret nobody else holds, or protocols designed for private set intersection.

Two other misuses come up often. A hash is not a compression algorithm, since nothing can be recovered from it. And a non-cryptographic hash such as CRC32 or MurmurHash is excellent for hash tables and checksums and useless where an adversary chooses the input, because collisions can be manufactured on purpose to degrade a data structure into a linear scan.

Frequently asked questions

What is HMAC and when do I need it?: HMAC combines a hash with a secret key to prove a message came from someone holding that key and was not altered. A plain hash proves neither, because anyone can recompute it. HMAC is what signs webhook payloads and API requests. Switch to HMAC mode and supply the key.
Is MD5 safe to use?: Not for security. MD5 has practical collision attacks and must never be used for passwords, signatures or integrity against a motivated attacker. It is still perfectly reasonable for non-adversarial uses such as checksums, cache keys and ETags, which is why it is included here.
How should I hash passwords then?: Not with any of these. Password storage needs a slow, salted algorithm designed for the job, such as bcrypt, scrypt or Argon2. A fast general-purpose hash like SHA-256 can be brute-forced at billions of guesses per second.
Is my input sent to a server?: No. SHA hashing uses the browser Web Crypto API and MD5 is implemented in JavaScript on the page, so your text never leaves your device.
Why is MD5 not in the browser Web Crypto API?: It was deliberately left out because it is cryptographically broken, so it is implemented separately here. The implementation is verified against the official RFC 1321 test vectors.
Does it handle non-English text?: Yes. Input is encoded as UTF-8 before hashing, so Japanese, Chinese, Korean and emoji produce the same hashes you would get from any standard command-line tool.

Last updated: 2026-09-18

Report a problem

Include the steps, expected result, and actual result. Remove secrets and personal data.