Hash Generator

Max 256 KB · Hashes automatically as you type

Algorithms

Processed entirely in your browser — nothing is sent to a server.

A hash function takes an input of any length and produces a fixed-length string of characters — the “hash” or “digest” — that acts as that input’s fingerprint. The same input always produces the same hash, a tiny change to the input produces a completely different hash (not a similar one), and — for a well-designed algorithm — there’s no practical way to work backwards from a hash to recover the original input, or to find two different inputs that hash to the same value. That one-way property is what separates hashing from encoding: Base64 or URL encoding are reversible by design, while a hash is deliberately not.

This tool computes five widely used hash algorithms — MD5, SHA-1, SHA-256, SHA-384, and SHA-512 — from any text you paste in, all client-side. SHA-1, SHA-256, SHA-384, and SHA-512 run through the browser’s built-in Web Crypto API (crypto.subtle.digest), the same native mechanism this site’s JWT Encoder uses for its HMAC signing. MD5 is not part of that API — it was deliberately left out as a legacy algorithm — so it’s implemented here directly in JavaScript, following its 1992 specification (RFC 1321), which hasn’t changed since.

MD5 and SHA-1 are not secure. Both have known, practical collision attacks: it’s possible to deliberately construct two different pieces of data that produce the same hash. That doesn’t make them useless — they’re still fine for catching accidental corruption, like confirming a file downloaded correctly — but neither should be used anywhere an adversary might benefit from forging a match: password storage, digital signatures, or verifying that a file hasn’t been tampered with by someone who wants it to look untampered. SHA-256 and above have no known practical attack and are the current standard for that kind of integrity check. None of the five algorithms here are appropriate for hashing passwords directly, regardless of strength — password storage needs a deliberately slow, salted algorithm (bcrypt, scrypt, Argon2) designed to resist brute-forcing, which is the opposite design goal of a general-purpose hash like SHA-256.

Every algorithm updates live as you type, debounced slightly so it doesn’t recompute on every keystroke, and each result has its own Copy button. Since hashed input can itself be sensitive — a password you’re checking, an API token, anything you wouldn’t want logged — this page never loads analytics and displays the same “processed entirely in your browser” guarantee as this site’s other sensitive-input tools.

Examples

Frequently asked questions

Is MD5 secure?
No — not for anything security-related. MD5 has been considered cryptographically broken since 2004: researchers can deliberately construct two different inputs that produce the same MD5 hash (a collision) using ordinary hardware. It should never be used to store passwords, sign data, or verify that a file hasn't been tampered with by an adversary. It's still useful for one narrow purpose: detecting accidental corruption, like confirming a download completed without a disk or network error, where nobody is deliberately trying to fool the check.
Is SHA-1 secure?
Also no. SHA-1 was formally broken in 2017 (the "SHANATTACK" collision, published by Google and CWI Amsterdam), and every major browser and certificate authority has since stopped trusting SHA-1 for TLS certificates and code signing. Like MD5, it's only appropriate today for non-adversarial checksums, not for passwords, signatures, or anything where someone might deliberately try to forge a match.
Which algorithm should I actually use?
SHA-256 for almost everything — it's the current standard for certificates, blockchain, package integrity hashes, and general-purpose checksums, with no known practical attack. SHA-384 and SHA-512 offer a larger output for applications that specifically call for it (they're not meaningfully "safer" than SHA-256 for most purposes, just bigger). None of the five algorithms here should be used to hash passwords directly — password storage needs a slow, salted algorithm designed for that purpose (bcrypt, scrypt, or Argon2), which intentionally makes brute-forcing expensive; general-purpose hashes like these are deliberately fast, which is exactly the wrong property for a password hash.
Why do I get a completely different hash for almost-identical input?
This is called the avalanche effect, and it's a deliberate design property of every algorithm here: changing even a single character should flip roughly half of the output bits, with no visible relationship between the old and new hash. It's what makes a hash useful as a checksum — a corrupted file produces an unrecognizably different hash rather than a "close" one, so there's no ambiguity about whether it matches.
Is my input sent to a server?
No. All five algorithms run entirely in your browser. SHA-1/256/384/512 use the browser's built-in Web Crypto API; MD5 (which that API deliberately does not implement, since it's a legacy algorithm) runs as plain JavaScript. Nothing you type is transmitted anywhere — see the privacy notice above the input for the technical basis of that claim.