Hash and Checksum Generator (MD5, SHA-256)

What a digest proves, and what it does not

A hash function takes an input of any size and returns a short, fixed-length fingerprint called a digest. Hash the same bytes twice and you get the same digest both times; change a single character and the digest changes beyond recognition. That is what makes a digest useful for comparing two things without passing both of them around: if the fingerprints match, the inputs matched.

A checksum is the same idea used for integrity rather than security. It answers the question "did this text arrive exactly as it left?", not "was this text written by somebody trustworthy?".

Digest sizes at a glance

MD5 is specified in RFC 1321, and the SHA family is specified by NIST in FIPS 180-4. Digest length alone tells you which algorithm produced a value, which is handy when a webhook hands you a checksum with no documentation attached.

Which algorithm fits which job

The right choice depends on who might want to lie to you. If nobody does — you are checking whether your own download finished intact, or whether two files differ — then any of these digests will do the job, and MD5 is the fastest. The moment an attacker has a reason to forge the value, the weak algorithms stop being usable, because both MD5 and SHA-1 have published collision attacks: two different inputs that produce the same digest on purpose.

Two of those rows are worth spelling out. A plain digest does not authenticate anything: if an attacker can change the file, they can change the checksum printed next to it, which is why real integrity systems sign the digest with a key rather than publishing it alone. And a password is not a file: it is short, it is guessable, and it has to be verified millions of times a day, so it needs a hash that is slow by design and salted per user — a job this tool deliberately does not do. If you are generating credentials rather than checking them, the password generator is the right tool, and if the digest you are looking at came from a signed token, the JWT decoder will show you the header that names the algorithm.

Reading the five digests side by side

1. Choose Text and type or paste the value, or choose File and pick a file from your disk.
2. All five digests are computed straight away - MD5, SHA-1, SHA-256, SHA-384 and SHA-512 - and each row has its own copy button.
3. Paste a checksum you were given into Expected checksum. The tool tells you which algorithm it matches, or explains why nothing matched.
4. Tick Uppercase output when the system you are comparing against prints checksums in capitals.

Nothing is uploaded. MD5 is implemented inside this page; the SHA digests are produced by your browser's built-in Web Crypto API, the same code path the browser uses for its own security work.

Hashing tips and gotchas

• Hashes work on bytes, not on what you see. A trailing space, a Windows CRLF instead of a Unix LF, or a curved quote pasted from a document editor will each produce a completely different digest.
• MD5 collisions can be constructed deliberately. Use MD5 to detect accidental corruption, never to prove that a file is genuine or that a message came from who it claims.
• A digest is not encryption. You cannot decrypt a hash, and storing a plain unsalted hash of a password is not safe, because short passwords can be looked up in precomputed tables within seconds.
• Do not confuse a hash with Base64. Base64 is a reversible encoding, so it hides nothing; a hash is one-way, but on its own it proves nothing about who created it. The Base64 encoder and decoder shows what the reversible direction looks like.

FAQ

Is MD5 still safe to use?

Not for security. Practical collision attacks against MD5 have been published since 2004, so two different inputs can be crafted to produce the same MD5 digest. MD5 remains fine for non-security jobs such as spotting an accidental file change or a typo, but use SHA-256 or better whenever an attacker has a reason to forge the value.

Can a hash be reversed back into the original text?

No. A hash function throws information away, so you cannot run it backwards to recover the input. What people do instead is hash a huge list of guesses and look for a match, which is why short or common strings such as single words are easy to look up in a precomputed table, and why passwords should be salted before they are stored.

Why did I get a different hash for text that looks identical?

Hashing works on exact bytes, not on appearance. A trailing space, a different line ending, a smart quote instead of a straight one, or a letter written in a different case can all change the digest completely. Compare the byte count shown above the results and make sure both sides hashed byte-for-byte identical input.