MD5 vs SHA-256 (and Why Neither Should Hash Your Passwords)

What a hash is - and what it is not

Hashing is not encryption. Encryption is reversible with a key; a hash has no key and no inverse. You hash a file to detect corruption or a change; you do not "decrypt" an MD5 back to the original. Any tool that claims to "decrypt" a hash is really just looking up the input in a precomputed table.

These generators compute a hash of text you type, entirely in your browser, and they do exactly that - nothing more. They have no salt, no iterations and no secret, which is precisely why they are fine for fingerprints and dangerous for passwords.

MD5: broken for security, still common for non-adversarial uses

MD5 produces a 32-character hex digest and its collision resistance is thoroughly broken - anyone can craft two different inputs with the same MD5 cheaply. That rules it out anywhere an attacker might exploit collisions: code-signing, certificate trust, integrity of files that a hostile party could tamper with, or "proof" two things differ.

It is still seen as a quick, non-security checksum (detecting accidental corruption, cache keys, dedup within trusted data) and in legacy systems. But when in doubt, reach for SHA-256 instead; the extra 32 characters are almost never a reason to use a broken primitive.

SHA-256: a sound choice for integrity and identity

SHA-256 (part of the SHA-2 family) has no practical collisions known and is the default for tamper-evidence and content addressing: it is what Git uses to name objects, what TLS certificates and software signatures rely on, and what blockchain-style digests use. If you need to prove a file has not changed, or to derive a stable ID from content, SHA-256 is the right tool.

It is fast by design, which is exactly what you want for hashing large volumes of public data - and exactly what you do not want for protecting a small secret, as the next section explains.

Why you must never store passwords with MD5 or SHA-256

Password verification is the opposite problem: you want hashing to be slow and expensive so brute force is costly, and you want it unique per user so one stolen table cannot be attacked in bulk. Fast general hashes give you neither - a GPU tries billions of SHA-256 (let alone MD5) attempts per second, and unsalted digests fall to rainbow tables. A single fast hash of a common password is effectively plaintext to a serious attacker.

The correct tools are deliberately slow, salted, work-factor key-derivation functions: Argon2id (memory-hard, current best practice) or bcrypt, with scrypt or PBKDF2 as alternatives. The salt makes each hash unique and defeats precomputed tables; the tunable cost makes guessing expensive. Our generators provide neither salt nor iterations, so they are the wrong class of tool for passwords by design.

A frequent confusion to kill outright: base64 is not hashing or encryption at all - it is a reversible encoding of arbitrary bytes into safe text. Anything base64-encoded can be decoded instantly; it provides zero confidentiality or integrity.