MD5 and SHA256 Hash Generator Free

What a hash actually is, and why the same input always gives the same digest

A hash function takes any input you can imagine, a word, a photo, a four-gigabyte installer, and returns a fixed-size string of characters. Run it twice on identical bytes and you get the identical string, every time, on every machine on earth. That determinism is the whole contract of a hash: the output is a fingerprint of the input, and the same fingers always leave the same print.

The second half of the contract is that the output never grows. MD5 returns 32 hex characters whether you hash one byte or ten gigabytes, because the algorithm squeezes the input through a compression function in 64-byte blocks and folds the result into a small register. Since a finite output cannot represent an infinite input, collisions (two inputs with the same digest) are mathematically guaranteed to exist somewhere. The interesting question is whether a human can find one on purpose, and for MD5 and SHA-1 the answer has been yes for years.

Hashes are also one-way in practice, not in theory. There is no button that turns a digest back into its input; an attacker has to guess candidates, hash each one, and compare. A long random input is safe from that approach because the guess space is absurd. A six-character password is not, which is exactly why password storage grew its own specialized algorithms years ago. We come back to that in the password hashing section below.

All four are shown side by side on this page on purpose. Real-world files still ship with an MD5 next to the SHA-256, and you cannot verify what you refuse to compute.

SHA-256 vs SHA-512: which one you should pick

SHA-256 and SHA-512 belong to the same family and share a design; the difference is word width and digest length. SHA-256 works on 32-bit words in 64-byte blocks, SHA-512 works on 64-bit words in 128-byte blocks, and SHA-512 pushes everything through more rounds with a larger initial state. On a 64-bit device that architecture often lets SHA-512 finish in less wall-clock time than SHA-256 while producing twice the output, though your browser, your CPU, and your JavaScript engine all have a say. We do not publish speed numbers here, because any timing we measured on one laptop would be fiction on yours.

The practical decision is almost never about speed. It is about what the other end expects. A Linux ISO page that publishes SHA-256 wants SHA-256; a Docker registry digest is SHA-256; TLS certificates, JWT signatures, and most checksum formats are SHA-256; Git object IDs are SHA-1 today, with SHA-256 repositories supported as well. Pick the algorithm the publisher picked, because a perfect hash of the wrong algorithm matches nothing. If you control both ends, or you simply want more room in the digest, SHA-512 is a fine default and this page computes it beside the others so the comparison costs one click.

What about SHA-384 and SHA-3?

SHA-384 is a truncated SHA-512 and shows up inside TLS cipher suites; SHA-3 is a different sponge design entirely. Both are available to JavaScript through the same Web Crypto interface, so if a spec demands them, a two-line change in the digest call is all it takes. This page ships the four values people are actually asked to produce by hand: MD5, SHA-1, SHA-256, SHA-512. Every extra checkbox would be one more thing to get wrong when you are matching strings at midnight.

Hashing passwords: why MD5 and SHA-256 are the wrong tool

It is tempting to take the hash you already know and use it for passwords: store the SHA-256 of the password, compare digests at login, done. It is also the single most common mistake in homemade authentication, and it fails for a reason that has nothing to do with the strength of the hash. A hash is designed to be fast. Password storage needs the opposite.

Speed is the attack surface. When verification takes microseconds, an attacker with a stolen database can test enormous numbers of candidate passwords against every hash in it, offline, without ever touching your login form. Two standard defenses follow from that. Salts (a random value per user, stored alongside) break precomputed tables, because the attacker must work on each account separately. Deliberate slowness, in the form of a dedicated password hashing function such as bcrypt, PBKDF2 or Argon2, raises the cost of every single guess, and those functions accept a work factor so the cost can be raised as hardware improves. None of that lives inside MD5 or SHA-256; you cannot bolt it on afterwards.

There is a second confusion worth clearing up: hashing is not encryption. Encryption must be reversible with the key, because the legitimate side needs the original value back. Hashing is deliberately not reversible, which is why it suits fingerprints and terrible at secrets you must return. For passwords the server only ever needs to compare, so a slow hash is correct. For a document you need to read again, use encryption. And on the generating side, the raw material matters more than the algorithm: a strong random password from the Password Generator gives the hash something worth protecting.

What we actually tested

This page makes specific claims, so here is how they were checked rather than asserted. The MD5 engine that ships with this site was verified against Node's crypto module across more than 400 test vectors, covering empty input, ASCII, multi-byte characters and random byte arrays. The SHA path uses the browser's own Web Crypto implementation, and during this build the same inputs (the empty string, "abc", and a one-megabyte random buffer) were run through both Web Crypto and Node's crypto module, with every digest matching character for character. The published SHA-256 digest of abc (ba7816bf...) also came out of the page unchanged, which is the check that catches a broken hex encoder.

The interface got the same treatment. Typing updates the digests after a short pause rather than on every keystroke, so a paste of a large document does not lock the tab. The uppercase toggle only re-renders the hex you already have; it never recomputes, which we confirmed by watching the network and the CPU at the same time. Dropping a file switches the source to its bytes and reports the exact size read, and typing again switches back to the textarea. The Copy button falls back to the older selection-based copy when the clipboard API is blocked, and that fallback was exercised in a browser with clipboard permissions denied.

On privacy, the check is the one anyone can run: open DevTools, keep the Network tab visible, hash text and drop a file, and watch it stay empty. There is no analytics call tied to the hashing path, no beacon, and nothing written to storage. Reload the page and your input is gone, because it was never anywhere else.