Hash Generator

Which algorithm to use

The honest answer for almost every new use: SHA-256. It is fast, universally supported, and has no known practical weakness. It is the default here for that reason.

The others are worth offering because the world is full of systems that already chose:

"Broken" has a precise meaning here. MD5 collisions can be produced in seconds on a laptop, and chosen-prefix collisions — two meaningful files with the same hash — are practical. SHA-1 fell the same way in 2017. So neither can be trusted where an attacker benefits from two inputs colliding: signatures, certificates, deduplicating untrusted uploads, integrity checks on a hostile network. Verifying that a file copied across your own LAN arrived intact is a different problem, and MD5 is perfectly adequate for it.

Never use these for passwords

This is the mistake with the worst consequences, so it deserves its own heading. A password database hashed with MD5, SHA-1 or even SHA-256 is barely protected: these functions are designed to be fast, and commodity hardware computes billions of SHA-256 candidates per second. A leaked table falls to a dictionary attack almost immediately.

Password storage needs a deliberately slow, salted, memory-hard function — Argon2id, scrypt or bcrypt — with per-user salts and a tuned cost factor. If you need a strong password rather than a hash of one, the password generator is next door.

Hashing a file

Pick a file and its digest is computed locally — the file is read into memory by your browser and never sent anywhere, which is the point. The usual use is verifying a download against a published checksum: hash the file you received, compare against the string on the vendor's page, and confirm the two match character for character.

One caveat on that workflow: a checksum served from the same site as the download proves only that the transfer was not corrupted. If the site itself was compromised, both were replaced. A signature you can verify against a key you already trust is what defends against that.

How this is implemented

SHA-1 through SHA-512 come from the Web Crypto API built into your browser, so they are native code, not JavaScript. Web Crypto is only exposed over HTTPS, which is why those algorithms are unavailable if you open this page from a local file.

MD5 is not in Web Crypto at all — deliberately, since the standard declines to bless broken primitives — so it is implemented here in JavaScript following RFC 1321. It is verified against the RFC's own test vectors and against block-boundary lengths, so its output matches md5sum and Python's hashlib exactly.

Common questions

Is my text or file uploaded?

No. Everything is computed in your browser, and the page makes no network requests. See the privacy policy.

Can a hash be reversed?

Not by inverting it — hashes discard information. But short or common inputs can be looked up in precomputed tables, which is why "reverse MD5" sites work at all on things like password123. That is a lookup, not a reversal.

Why does an empty input still produce a hash?

Because the empty string is a valid input. d41d8cd98f00b204e9800998ecf8427e is the MD5 of nothing at all, and recognising it on sight is a useful habit — it usually means a file failed to load.

Do trailing newlines change the result?

Yes, completely. Hashes have no notion of insignificant whitespace, so a stray newline at the end of a file produces an entirely different digest. This is the most common reason a checksum comparison fails when the content looks identical.

• Base64 encoderUTF-8 safe encoding and decoding, with a URL-safe option.
• Password generatorStrong random passwords with the exact entropy shown.