Hash Generator — MD5 and SHA

What a hash function actually does

A cryptographic hash function takes an input of any length and produces a fixed-length output — the digest. SHA-256 always returns 256 bits, whether you feed it one character or a gigabyte of video. The mapping is deterministic, so the same bytes always produce the same digest, and it is designed to be one-way: given a digest there should be no practical way to recover the input, and no practical way to find a second input that produces the same digest.

That last property is what makes a hash useful as an identity check. If you and a server independently hash the same request body and get the same value, the bodies are identical down to the byte — including trailing whitespace and line-ending differences that a visual comparison would never catch. If the digests differ, something changed, even if you cannot see what. When you need to see what changed rather than merely that something changed, the text diff checker is the tool for that job; a hash only ever answers yes or no.

A useful mental model is that hashing throws information away on purpose. Encryption is a reversible transformation — hold the key and you get the plaintext back. A digest is a lossy fingerprint. There is no "MD5 decrypter", and the sites that advertise one are simply looking your digest up in a precomputed table of strings people have hashed before. That works beautifully for password123 and not at all for a random 32-byte token.

Where digests show up in API work

• Webhook signatures. A provider signs the raw request body with a shared secret and sends the result in a header; you recompute it and compare. Getting this right is the main reason to care about hashing when you are building an integration.
• ETags and caching. Many servers derive an ETag from a digest of the response body so a conditional request can return 304 Not Modified instead of resending it.
• Content addressing. Git names every object by the digest of its contents; container image layers and package lockfiles work the same way.
• Integrity checks. Release pages publish a SHA-256 next to a download so you can confirm the bytes you received are the bytes that were published.
• Idempotency keys and deduplication. Hashing a normalised payload gives you a stable key for "have I already processed this exact request?"

Which algorithm should you use?

MD5 and SHA-1 are cryptographically broken

This needs to be stated plainly rather than hedged. MD5 is broken. Collisions — two different inputs with the same digest — have been constructible since 2004, and today a chosen-prefix collision can be produced on ordinary hardware. SHA-1 is broken too. The SHAttered research published in 2017 produced two different PDF files with the same SHA-1 digest, and follow-up work reduced the cost of a chosen-prefix collision to something a well-funded attacker can rent by the hour. Browsers and certificate authorities stopped accepting SHA-1 certificates years ago.

Concretely, that means neither algorithm may be used for a digital signature, a certificate, a commit-signing scheme, a licence check, an anti-tamper mechanism, or anything else where an adversary benefits from making two inputs collide. They remain acceptable for exactly one class of job: detecting accidental corruption, where nobody is trying to fool you — a truncated download, a flaky disk, a cache key. The generator above includes both because you will still meet them in the wild, in old protocols and vendor documentation, not because you should reach for them.

Never hash passwords with these

A password database protected with SHA256(password) is barely protected at all, and adding a salt only partially helps. The entire SHA family is engineered for speed, which is a virtue for integrity checking and a catastrophe for password storage: commodity GPUs try billions of SHA-256 guesses per second, so a stolen table of fast hashes falls to a dictionary attack quickly. Password verification needs a deliberately expensive function with a tunable work factor and, ideally, a tunable memory cost: Argon2id first, scrypt or bcrypt if Argon2 is not available in your stack. Every one of them salts automatically and stores its parameters alongside the digest so the cost can be raised later.

Sign requests with HMAC, not a bare hash

A tempting but wrong way to authenticate a webhook is SHA256(secret + body). Because SHA-1 and SHA-2 use the Merkle–Damgård construction, an attacker who knows a valid digest and the message length can append data and compute a valid digest for the extended message without knowing the secret at all — a length-extension attack. HMAC exists to close that hole by hashing twice with two derived keys. If you are validating an incoming webhook, compare using a constant-time comparison as well, so response timing does not leak how many leading bytes were correct. The webhook tester walks through what a signed delivery looks like on the wire, and the HTTP headers reference covers the headers providers use to carry signatures and timestamps.

Using this hash generator

Type or paste your text and press Hash. All five digests are computed at once, so you do not have to guess which algorithm a system used — paste the checksum you were given into the comparison field and the matching row is marked for you. The encoding selector switches between lowercase hex, uppercase hex and Base64. These are three renderings of the same bytes, and mixing them up is a common source of "the signature does not match" bugs: AWS-style signatures use lowercase hex, while many webhook providers Base64-encode the same digest.

Encoding matters as much as the algorithm

A digest is a sequence of bytes with no inherent text form. Before comparing two digests, make sure both sides agree on the representation, on whether the hex is upper or lower case, and — most importantly — on exactly which bytes were hashed. Hashing the pretty-printed version of a JSON body produces a completely different digest from hashing the minified version, which is why signature schemes always specify the raw body as received. If you need to normalise a payload before hashing it, the JSON formatter can minify it deterministically first, and the Base64 encoder converts between Base64 and plain text when a provider hands you a digest in the other encoding.

Line endings are the usual culprit

When a digest you compute locally disagrees with one computed elsewhere and everything else looks right, suspect the newlines. A file checked out on Windows with CRLF line endings hashes differently from the same file with LF endings, and a textarea in a browser normalises what you paste. A trailing newline at the end of a file counts too. This is not a flaw in the hash — it is the hash doing its job and telling you the bytes genuinely differ.

Secure contexts

crypto.subtle, the browser API this page uses for the SHA family, is only exposed in a secure context: HTTPS, or localhost during development. On a plain http:// page the property is simply undefined, which is a surprise the first time you hit it on a staging server. This site is served over HTTPS, so all five algorithms work here; if you copy this technique into your own project, make sure the page is not served over plain HTTP.

Frequently asked questions

Related tools and reference