Hash Generator

How to use it

1. Type, paste, or drop a file. All five digests appear at once — no dropdown, no re-running for each algorithm.
2. To verify a download, drop the file in and paste the published checksum into the verify box. You get a plain match or no-match answer.
3. Copy the one you need. Each row has its own copy button.

Files are read with the browser’s FileReader and hashed locally. Nothing is uploaded, so a 4GB ISO never leaves your machine.

Do not use this for passwords

This section comes first because it’s the most important thing on the page, and because “sha256 hash generator with salt” is one of the most common ways people arrive here.

SHA-256 is the wrong tool for storing passwords, and adding a salt does not fix it.

The reason is speed. SHA-256 is designed to be fast — that’s a feature for checksums, where you might hash gigabytes. It’s a catastrophe for passwords. Commodity hardware computes billions of SHA-256 hashes per second. If your user database leaks, an attacker runs through every common password, every dictionary word, and every short combination in hours.

A salt is a unique random value stored with each hash. It does two useful things: it stops one precomputed rainbow table from cracking every account at once, and it means two users who picked the same password get different hashes. Both are necessary. Neither slows the attacker down per guess, which is the actual problem.

What you want is a hash deliberately built to be slow and memory-hungry:

• Argon2id — the current recommendation. Tunable memory cost resists GPU and ASIC attacks.
• scrypt — also memory-hard, widely available, a solid choice.
• bcrypt — older but battle-tested and still fine. Note its 72-byte input limit.

All three handle salting for you and let you raise the cost as hardware gets faster. Use your platform’s implementation rather than assembling one; this is not a place to improvise.

What a hash is

A cryptographic hash turns input of any length into a fixed-size value. The same input always produces the same digest, and changing one bit changes roughly half the output bits — so hello and hellp produce results with nothing visibly in common.

Three properties matter:

• Deterministic. Same input, same output, on any machine, forever.
• One-way. There’s no function to recover the input. Information is genuinely discarded.
• Collision-resistant. It should be impractical to find two inputs producing the same digest. This is the property MD5 and SHA-1 have lost.

“One-way” is often misread as “unbreakable”. If the input space is small — a 6-digit PIN, a common password, a known phrase — an attacker just hashes every candidate until one matches. The function isn’t reversed; it’s outrun.

Which algorithm to use: SHA256, MD5 or SHA-1

“Broken” needs qualifying, because it doesn’t mean “useless”.

MD5 collisions can be produced deliberately in seconds. Two different files can be crafted to share a digest. That destroys MD5 for anything where an attacker chooses the input — signatures, certificates, integrity checks against tampering. It does not stop MD5 detecting accidental corruption, which is why plenty of mirrors still publish MD5 sums alongside SHA-256 ones.

SHA-1 fell the same way in 2017 with the SHAttered attack, which produced two PDFs with the same digest. Same conclusion: fine as a non-adversarial identifier, unsuitable where someone might be trying to fool you.

If you’re choosing today and have no legacy constraint, use SHA-256.

“MD5 decrypt” is not a thing

This is the single most searched question about MD5, so it deserves a straight answer: MD5 cannot be decrypted, and neither can any other hash. Not by this tool, not by a better tool, not by anyone.

The reason is structural rather than a matter of effort. Encryption is reversible by design — it takes your data and a key and produces something that the key turns back. Hashing is not encryption. It takes an input of any length and produces a fixed 128 bits, and in doing so it throws information away permanently.

Hash a one-word password and you get 128 bits. Hash the complete works of Shakespeare and you get 128 bits. The second one clearly cannot contain the book. There is nothing to reverse, because the information is gone.

What people searching for it actually want

Usually one of three things:

• They have a hash and want the original password. What they’re after is a rainbow-table lookup — a giant precomputed database of common inputs and their hashes. That’s not decryption, it’s a search. It only works when the input was already in someone’s list.
• They’ve been handed a hash and assumed it was encrypted. Reasonable mistake. “Encrypted” gets used loosely for anything that looks like gibberish.
• They want to check whether a password matches a stored hash. That’s a normal, correct operation — hash the candidate and compare. It doesn’t require reversing anything.

Why we won’t do the lookup

We could host a rainbow table. We’ve chosen not to, for two reasons.

The first is that it’s a credential-cracking service wearing a helpful hat. The realistic use for “paste a hash, get the password” is a hash you obtained from somewhere you shouldn’t have. There’s no version of that feature that only helps the well-intentioned.

The second is that it would misinform people about how hashing works. A tool that “decrypts” MD5 four times out of five teaches its users that hashes are reversible — right up until they rely on that belief for something that matters.

If you legitimately need to recover a password you own, the answer is your password manager or a reset link, not a hash lookup.

Why MD5 is unfit for passwords

Even with a rainbow table off the table, MD5 is the wrong tool for storing passwords — and the reason is the opposite of what people assume. It isn’t too weak to compute. It’s too fast.

A password hashing function is supposed to be slow, and tunably so, because the attacker is running the same function you are. MD5’s whole design goal — hash a lot of data quickly — is exactly the property that makes it useless here. SHA-256 is no better for this purpose, despite being cryptographically sound in every other respect.

Use bcrypt, scrypt or argon2, each with a per-user salt. That is the entire recommendation, and it hasn’t changed in years.

Verifying a download

This is what most people actually need a hash for, and it’s the workflow this tool is built around.

A project publishes its release alongside a checksum. You download the file, hash it yourself, and compare. If they match, your copy is byte-identical to what was published — no truncated transfer, no corrupted mirror, no tampering in transit.

1. Drop the downloaded file onto this page.
2. Copy the published checksum from the project’s site.
3. Paste it into the verify box.

You get an explicit verdict rather than squinting at two 64-character strings. Paste a whole line from a SHASUMS256.txt file if you like — a trailing filename is ignored, and case doesn’t matter.

One thing a checksum can’t do: prove the file is legitimate. If an attacker controls the download page, they control the checksum on it too. Checksums protect against corruption and against a compromised mirror when the checksum comes from elsewhere. For genuine authenticity you need a signature — GPG, minisign, or a platform’s code signing — where the trust comes from a key you already have.

Worked examples

The empty string. Hashing nothing at all gives e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 for SHA-256. That value is worth recognising — if a system stores it, something hashed an empty field. It’s also a quick way to confirm any hashing tool is behaving, and this page’s test suite checks it.

The avalanche effect. Hash hello, then Hello. One bit of difference in the input, and the two digests share nothing. That’s what makes a hash useful as a fingerprint: there’s no partial match, no “close enough”.

Unicode is hashed as bytes. Hashing café hashes the UTF-8 encoding, which is 5 bytes rather than 4 characters. A system that used a different encoding — Latin-1, say — produces a completely different digest for text that looks identical. When two systems disagree about a hash, character encoding is the first thing to check.

Doing it elsewhere

Digests from all of these should match this page exactly for the same bytes. Our implementation is tested against Node’s crypto module for every algorithm listed.

Common mistakes

Using a fast hash for passwords. The big one. Covered above.

Comparing digests by eye. People check the first and last few characters and call it a match. An attacker who can produce a near-miss knows this. Compare the whole string, or let the tool do it.

Hashing the wrong thing. Hashing a filename instead of its contents, or a string representation of a number instead of its bytes. If two systems disagree, check what exactly each is feeding in.

Trusting a checksum from the same page as the download. It only helps against accidental corruption. If the page is compromised, both are.

Assuming a longer hash is more secure for your purpose. SHA-512 isn’t meaningfully safer than SHA-256 for checksums; it’s just longer. Both are unbroken. Pick on compatibility, not digest size.

Expecting encryption. Hashing is one-way. There’s no way to get the original back, by design. If you need to recover the data later, you want encryption instead.

HMAC: hashing with a key

A plain hash proves nothing about who produced it. Anyone can hash a message, so anyone can produce a matching digest for altered content. HMAC fixes that by mixing a secret key into the hashing process.

The point is authentication, not secrecy. If you and a service share a key, an HMAC over a message proves the message came from someone holding that key and hasn’t been altered since. Webhook providers use this constantly — Stripe, GitHub and most others sign their payloads with HMAC-SHA-256 so your endpoint can reject anything forged.

Two things people get wrong. First, HMAC is not “hash the key plus the message” — that naive construction is vulnerable to length-extension attacks against SHA-2, which is exactly why HMAC’s two-pass design exists. Use your platform’s HMAC function rather than concatenating anything yourself. Second, comparing HMACs with a normal string comparison leaks timing information; use a constant-time comparison such as hmac.compare_digest in Python or crypto.timingSafeEqual in Node.

This tool doesn’t generate HMACs, because doing so would mean typing a production secret into a web page. Even though nothing here leaves your browser, that’s a habit worth not building.

Collisions, and the numbers behind them

A collision is two different inputs producing the same digest. Collisions always exist — a hash maps infinite inputs onto a fixed number of outputs — so the question is only whether anyone can find one.

SHA-256 has 2²⁵⁶ possible outputs, which is roughly 1.16 × 10⁷⁷. The birthday paradox means a collision becomes likely after about 2¹²⁸ hashes rather than 2²⁵⁶, and 2¹²⁸ is still around 3.4 × 10³⁸. No amount of hardware brings that within reach.

Compare MD5. Its 128-bit output puts the birthday bound at 2⁶⁴, which was already uncomfortable, and cryptanalysis dropped the real cost far below that. Deliberate MD5 collisions now take seconds on a laptop. SHA-1’s practical break in 2017 cost roughly 2⁶³ operations — expensive at the time, cheap now.

What this means in practice: for accidental corruption, even MD5 is overwhelmingly reliable. For anything where someone might be constructing input deliberately, MD5 and SHA-1 offer no protection at all, and the gap between those two situations is the entire reason both algorithms still appear on this page with a warning next to them.

Related tools

Hashes and encodings get confused constantly: a hash is one-way, Base64 is not. The Base64 encoder is the tool you want if you need something reversible. A JWT signature is an HMAC over Base64url data, which the JWT decoder will show you. For escaping values in a URL rather than fingerprinting them, use the URL encoder.