Hash some text
Type or paste, and five digests appear together. Change one character and watch every one of them change completely.
How it works
A hash function turns any quantity of text into a fixed-length fingerprint. The same input always gives the same digest, and flipping a single bit of the input flips roughly half the bits of the output. That avalanche is what makes a digest worth comparing: two inputs differing anywhere at all produce results with no visible resemblance, so nobody has to squint at them.
Collision resistance is the property that broke
Two guarantees matter here and they are not the same one. Preimage resistance means nobody can work backwards from a digest to text that produces it. Collision resistance means nobody can construct two different inputs sharing a digest. MD5 lost collision resistance in 2004. SHA-1 followed in 2017, when researchers at Google and CWI Amsterdam published SHAttered: two PDF files, visibly different on screen, carrying one identical SHA-1 value.
Neither has a practical preimage attack even now, and that distinction decides whether an aging algorithm is dangerous or merely old. Checking a download against a published checksum guards against a truncated transfer or a failing disk, and MD5 does that as well as anything newer. Signing a certificate with the same function lets somebody prepare a second document that validates under your signature. Identical arithmetic, opposite verdicts, and what separates them is whether an adversary chooses part of the input.
A password needs a slow hash, not one of these
Every algorithm on this page is built for speed, and speed is the wrong property for a password. A current graphics card computes billions of SHA-256 digests a second, so a stored digest of any password a person invented falls in about the time it takes to read this paragraph. Adding a salt stops one precomputed table being reused across a whole user list, which is worth doing and does nothing at all to the guessing rate.
Password storage wants bcrypt, scrypt or Argon2 instead. Each takes a deliberate work factor: a cost you raise until one verification occupies a few hundred milliseconds of your own hardware, which puts offline guessing somewhere between expensive and pointless. Argon2 also demands a fixed quantity of memory per attempt, and that is the part a graphics card cannot cheaply parallelise. Anyone who came here meaning to hash a password before storing it wants one of those three.
Hex and Base64 describe the same bytes
A digest is a run of bytes: sixteen of them for MD5, twenty for SHA-1, thirty-two for SHA-256. Hexadecimal spends two characters per byte, so those become strings of thirty-two, forty or sixty-four characters. Base64 spends four characters per three bytes and comes out about a third shorter, at the cost of a mixed-case alphabet that people mistranscribe. Checksum files and command-line tools print hex. Subresource integrity attributes and HTTP Digest headers carry Base64. Converting between the two changes nothing about the value underneath.
Which bytes actually get hashed
A hash function has no concept of characters, only bytes, so text encoding is part of the input rather than a detail alongside it. This page encodes as UTF-8, which is what nearly everything else now does. Any character outside ASCII costs more than one byte: é takes two, most CJK characters take three. Feeding the same visible string in as UTF-16 would give an unrelated digest, with nothing on screen to suggest why.
Three smaller differences account for most of the mismatches people bring here. A trailing newline is invisible and changes the answer completely, and the shell builtin echo appends one before the pipe unless you pass it -n. Windows line endings do the same thing once per line, a carriage return that nothing displays. The third is normalisation: an accented letter can be stored as a single code point or as a plain letter followed by a combining accent, identical on screen and different in bytes. The counts beside the result name both, which is the quickest way to catch any of them.
Questions
Why offer MD5 if it is broken?
Because a great many checksum files, package manifests and older systems still print one, and declining to compute it does not make any of them go away. Use it to confirm that a copy of something arrived intact. Avoid it anywhere an adversary chooses part of the input, which covers signatures, tokens, and deduplication a hostile uploader can reach.
Can the original text be recovered from a digest?
Not by reversing the function, which discards the length along with everything else. Guessing works, though: hash candidate inputs until one matches. For anything short or predictable, a password, a phone number, an email address, that search finishes fast, and tables of precomputed digests for common strings are published. Treat a digest of a short input as public.
Which algorithm should I pick?
SHA-256, unless something you are working with dictates otherwise. It is the default in TLS, in package managers and in most signing formats, it has no known weakness, and every language can read it. SHA-512 is not meaningfully stronger in practice and is often quicker on 64-bit machines. SHA-384 exists mostly because some standards specify that output length.
Why does my terminal print a different digest for the same text?
Almost always the bytes differ rather than the algorithm. A trailing newline is the usual cause, Windows line endings the next, and a stray space on the end of a paste after that. Compare the byte count shown with the result against the length you expect before suspecting the arithmetic. The trailing-newline toggle reproduces what a shell pipeline feeds in.
Can it hash a file instead?
No, this one takes text. A file checksum reads bytes straight off the disk with no encoding decision in between, which is a genuinely different job. Pasting a file's contents into the box usually gives a different answer than a checksum of the file, because the paste drops the exact line endings and any final newline the file carried.