Hash Generator

Paste anything and get MD5, SHA-1, SHA-256, SHA-384 and SHA-512 at once, computed in your browser. The report says which of them are safe to rely on, and explains the trailing newline that makes half of all hash comparisons disagree.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Hash. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

Hashing a password

Why a general-purpose hash is the wrong tool for a password, whatever the algorithm

password123

MD5 and SHA-1

Both still computed, both broken for anything an attacker can influence

hello world

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Hashing passwords with SHA-256

    General-purpose hashes are designed to be fast, which is exactly wrong for a password. A GPU tries billions of candidates per second against one.

    Instead:Use bcrypt, scrypt or Argon2. They are deliberately slow and salted, and the cost is tunable as hardware improves.

  2. Using MD5 to detect tampering

    Collisions are trivially constructible, so an attacker can produce a different file with the same digest. It is fine as a non-adversarial checksum and useless as a security control.

    Instead:SHA-256 for anything an attacker could influence.

  3. Comparing digests with a normal equality check

    A byte-by-byte comparison returns early on the first difference, which leaks how much of the value matched.

    Instead:Use a constant-time comparison from your language's crypto library.

What makes this one different

Every hash tool prints the same hex. The useful part is knowing which digest to trust and why yours does not match the one from the command line.

The newline problem, named

The most common reason a hash here disagrees with sha256sum is a trailing newline. echo adds one and echo -n does not, so the same text gives two different digests. Your input is hashed exactly as pasted, and the note under the output says which case you are in.

MD5 is included, with the caveat

WebCrypto refuses MD5 on purpose, so this page carries its own implementation, verified against the RFC 1321 vectors. It is here because S3 ETags, Docker digests and old checksum files still use it, and it is labelled broken for anything an attacker would want to forge.

It will not pretend to reverse one

Paste something that is already a digest and it says so, rather than quietly hashing the hash. Hashing is one-way. Sites offering to decrypt an MD5 are looking it up in a table of previously-hashed common strings, which is why it only ever works on short or obvious inputs.

It tells you when not to use it

If what you pasted looks like a password, the report says plainly that none of these digests is the right way to store it. SHA-256 is built to be fast, which is exactly wrong for passwords; bcrypt, scrypt and Argon2id are slow on purpose.

What is a hash, and why can it not be reversed?

A cryptographic hash takes input of any length and produces a fixed-length digest. A one-character file and a one-terabyte file both come out of SHA-256 as exactly 64 hex characters. That fixed size is the reason the process cannot be undone: the output has nowhere to store what went in.

Fixed output means information is destroyed

SHA-256 has 2 to the power of 256 possible outputs and an unlimited number of possible inputs, so infinitely many inputs map to each digest. Reversing one is not difficult, it is undefined: there is no single answer to return. Sites offering to decrypt a hash are doing something else entirely: hashing millions of common inputs in advance and checking whether yours is in the list, which works for password and fails for anything you actually chose.

""                          -> e3b0c44298fc1c149afbf4c8996fb924...
"a"                         -> ca978112ca1d0dbf3d0d4d5d7d1b4b6f...
a 4 GB disk image           -> 9f86d081884c7d659a2feaa0c55ad015...

every one of them is exactly 64 hex characters

A one-bit change rewrites the whole digest

Good hash functions have the avalanche property: flipping a single bit of input changes roughly half the output bits. This is what makes a hash useful for integrity: there is no such thing as a nearly-matching digest, so you cannot tell from two hashes whether the files were similar. Comparison is all or nothing.

"hello"   -> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c...
"hellp"   -> 7f2f8d1e1a5c2b8e9d3f4a6c8b0d2e4f6a8c0e2f...

one letter apart, nothing in common

Collisions are what break a hash function

A collision is two different inputs with the same digest. They exist for every hash function by counting alone; what matters is whether anyone can produce one deliberately. MD5 fell in 2004 and takes seconds today. SHA-1 fell in 2017 with SHAttered. Both are still fine for catching accidental corruption, which is why S3 ETags and Git object ids still use them, and both are useless anywhere an adversary would gain from forging a match.

Why none of these should hash a password

SHA-256 is designed to be fast, and speed is exactly the wrong property here. A GPU tries billions of candidates a second against a stolen database, and because plain digests are unsalted, identical passwords produce identical hashes, so one crack unlocks every account that shared it. Password hashing needs a function that is deliberately slow and salted per user: bcrypt, scrypt or Argon2id. Every mainstream language ships one.

sha256("hunter2")   fast, unsalted, identical for every user
bcrypt("hunter2")   slow by design, unique salt per hash

$2b$12$Ke9Xy... the $12$ is the cost factor: raise it as hardware improves