Hash Generator

Every algorithm below is explained in the same four steps: what it is in plain words, the intuition of how it works without any formulas, whether you should still use it today, and the mistakes people most often make with it.

What it is. MD5 (1992) compresses any input into a 128-bit (32 hex characters) fingerprint. It was designed to be fast on the computers of the 1990s, and it is — which is exactly why it is still everywhere: software download pages, file deduplication caches, legacy database keys.

How it works, intuitively. The input is cut into 64-byte chunks. Each chunk is stirred into a 128-bit rolling state four times over (four slightly different mixing rounds), and after the last chunk the state is printed as the digest. The stirring is built from additions, rotations and table lookups — cheap then, cheap now.

Should you use it? For checksums where nobody is trying to cheat you — detecting a corrupted download, finding duplicate files — yes, it still reports corruption perfectly. For anything adversarial, no: since 2004 researchers can craft two different files with the same MD5 in seconds, and real certificate forgeries using MD5 collisions happened in 2008. Treat it as a serial number, not a lock.

Common mistakes. Using MD5 for passwords (far too fast — see the Password Hash Generator for what belongs there instead); trusting a file because “the MD5 matches” when the attacker also published the MD5; and pasting the whole MD5 (file) = hash line instead of just the hash — the Verify box above accepts both.

What it is. SHA-1 (1995, NSA) produces a 160-bit (40 hex characters) digest. For twenty years it was the default integrity hash of Git, TLS certificates and PGP signatures.

How it works, intuitively. Same family recipe as MD5 but with a 160-bit state, 80 mixing rounds per 64-byte chunk, and a wider set of operations. The extra rounds were meant to make the blender harder to reverse-engineer.

Should you use it? No, for anything adversarial. The theoretical break became practical in 2017 when Google produced two different PDFs with identical SHA-1 values (the SHAttered attack, at ~6500 CPU-years). Git still stores objects under SHA-1 but treats it only as an identifier, and has since added collision detection. For new work use SHA-256 or SHA-3.

Common mistakes. Believing 160 bits “is still long enough” — the break is about the internal structure, not brute force; and mixing up RIPEMD-160 with SHA-1 because both are 40 hex characters long (the identifier box above distinguishes them).

What it is. The SHA-2 family (2001, NSA) is the workhorse of modern integrity checking. SHA-256 gives 256 bits (64 hex characters), SHA-512 gives 512 bits, and SHA-384 is SHA-512 with the result cut to 384 bits — useful when a protocol mandates a shorter tag.

How it works, intuitively. Chunks of 64 bytes (or 128 bytes for the 512-bit variants) are folded into an 8-word state through 64 (or 80) rounds of add-rotate-mix steps. Unlike MD5 the schedule first stretches each chunk into an expanded buffer, which is what defeated the style of attack that broke MD5 and SHA-1. A curiosity worth knowing: on 64-bit CPUs SHA-512 is faster than SHA-256, because it processes twice the data per round with 64-bit arithmetic.

Should you use it? Yes — SHA-256 is the default answer for file checksums, code signing and certificate fingerprints today, with no practical break known after two decades of analysis. Use SHA-384/512 when you want more margin or when the platform runs them faster.

Common mistakes. Using SHA-256 alone for passwords — it is a fast hash, and speed is the enemy there (use bcrypt/scrypt/Argon2id); and confusing the digest length with strength for adversarial collision resistance settings — the length only sets the ceiling.

What it is. SHA-3 (2015, standardized from the Keccak submission by Bertoni, Daemen, Peeters and Van Assche) is the third NIST hash standard. It shares nothing with the SHA-2 internals — it was selected precisely to be an independent backup in case SHA-2 ever falls.

How it works, intuitively. Instead of stirring chunks through a small state, Keccak repeatedly “soaks and squeezes”: the input is absorbed bit by bit into a 5×5×64-bit sponge, the whole sponge is scrambled by a fixed permutation (24 rounds of bitwise operations over the entire state), and digest bits are then squeezed out. The sponge picture is the whole idea: capacity bits are never output, and they are what makes the function one-way.

Keccak-256 vs SHA3-256. They differ in exactly one padding byte. The Keccak team’s original submission padded the last block with 0x01; NIST changed the standard padding to 0x06 (domain separation with SHA-2-era Keccak uses). Ethereum adopted the original padding, so its “keccak256” differs from standard SHA3-256 for every input. This page offers both, ticked separately.

Should you use it? Yes — either as your primary choice when policy wants a non-SHA-2 algorithm, or wherever the ecosystem already speaks it. Common mistakes: assuming SHA3-256 and Keccak-256 are interchangeable (they are not — compare the two rows this page produces for the same input); and assuming “SHA-3” supersedes SHA-2 — both are secure, SHA-2 remains the more widely deployed one.

What it is. RIPEMD-160 (1996, the RIPE consortium of European academics, strengthened by Dobbertin, Bosselaers and Preneel) outputs 160 bits. It is an entirely European design, deliberately independent of the NSA-designed SHA family.

How it works, intuitively. Each 64-byte chunk is processed by two parallel lines of 80 rounds with different constants and rotation amounts; at the end the two lines and the old state are combined. The two-track structure was the designers’ way to resist the differential attacks that were breaking other 1990s hashes.

Should you use it? In practice it survives mainly inside other systems: Bitcoin addresses hash their public keys with RIPEMD-160(SHA-256(pk)), older OpenPGP keys offer it as a hash option, and it is the traditional hash for BitTorrent v1 pieces alongside SHA-1. It has no practical collision attack, but the 160-bit size gives it the smallest safety margin on this page. For new standalone use prefer SHA-256 or SHA-3.

Common mistakes. Believing the two parallel lines make it “twice as strong” — output size is what limits collision resistance; and confusing it with SHA-1 (same 40-hex-character length; the identifier box above lists both possibilities side by side).

What it is. BLAKE2 (2013, Aumasson, Neves, Wilcox-O’Hearn and Winnerlein) is a hash designed for software speed: BLAKE2b targets 64-bit platforms with up to 512-bit output, BLAKE2s targets 32-bit platforms with up to 256-bit output.

How it works, intuitively. It descends from the SHA-3 finalist BLAKE, whose core is a keyed permutation borrowed from the stream cipher ChaCha: a 4×4 matrix of words is scrambled by alternating column and diagonal mixing steps — like shuffling a grid first top-to-bottom, then along the diagonals — for 12 (BLAKE2b) or 10 (BLAKE2s) rounds per chunk. Because those steps map beautifully onto CPU instructions, BLAKE2 is often faster than MD5 while offering security comparable to SHA-3.

Should you use it? Yes — it is a fully modern, unbroken design, popular in performance-sensitive software (package integrity in some ecosystems, content-addressed storage, backup deduplication) and as a fast MAC. On this page, BLAKE2b-512 gives the longest digests and BLAKE2s-256 the compact modern option.

Common mistakes. Thinking “faster must mean weaker” — BLAKE2 is faster by design, not by corner-cutting; and not realizing BLAKE2 also accepts a key (making it a MAC) or a personalization string — this page always uses it in plain unkeyed mode.

Verify. The verify box normalizes whatever you paste — upper or lower case, colons every two digits, a sha256= prefix, the BSD-style SHA256 (file) = hash wrapper, a GNU md5sum line with the filename after the hash, stray \r\n — then recomputes every ticked algorithm over your current input (text or the chosen file) and reports each algorithm that matches. A green match means “these bytes are exactly what the publisher hashed”; red means none of the ticked algorithms produced it — try ticking more algorithms, or check whether the paste was truncated.

Identify. The identifier box does not hash anything; it reads the shape of the string. Length narrows the candidates: 32 hex characters could be MD5, 40 could be SHA-1 or RIPEMD-160, 64 could be SHA-256 / SHA3-256 / Keccak-256 / BLAKE2s-256, 96 SHA-384, 128 SHA-512 / SHA3-512 / BLAKE2b-512. Prefixes reveal password hashes ($2a$/$2b$/$2y$ bcrypt, $argon2id$, $scrypt$, $6$ sha512crypt, $1$ MD5-crypt) — those are a different species (see the Password Hash Generator) and are deliberately not computed by this page. A string with +, / and = whose length is a multiple of 4 is more likely Base64-encoded data than a hex digest; the tool decodes it and reports the byte length it would correspond to.

What identification can and cannot tell you. Length and character set are fingerprints of the format, not proof of the algorithm: two 64-hex-character strings may have come from SHA-256 or from truncated SHA-512. The identifier ranks possibilities; the Verify box is the one that proves which algorithm your bytes actually match.

Algorithm	Digest	Invented	Digest of “The quick brown fox jumps over the lazy dog”
MD5	128 bit	1992	9e107d9d372bb6826bd81d3542a419d6
SHA-1	160 bit	1995	2fd4e1c67a2d28fced849ee1bb76e7391b93eb12
SHA-256	256 bit	2001	d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592
SHA-384	384 bit	2001	ca737f1014a48f4c0b6dd43cb177b0afd9e5169367544c494011e3317dbf9a509cb1e5dc1e85a941bbee3d7f2afbc9b1
SHA-512	512 bit	2001	07e547d9586f6a73f73fbac0435ed76951218fb7d0c8d788a309d785436bbb642e93a252a954f23912547d1e8a3b5ed6e1bfd7097821233fa0538f3db854fee6
SHA3-256	256 bit	2015	69070dda01975c8c120c3aada1b282394e7f032fa9cf32f4cb2259a0897dfc04
SHA3-512	512 bit	2015	01dedd5de4ef14642445ba5f5b97c15e47b9ad931326e4b0727cd94cefc44fff23f07bf543139939b49128caf436dc1bdee54fcb24023a08d9403f9b4bf0d450
Keccak-256	256 bit	pre-2015	4d741b6f1eb29cb2a9b9911c82f56fa8d73b04959d3d9d222895df6c0b28aa15
RIPEMD-160	160 bit	1996	37f332f68db77bd9d7edd4969571ad671cf9dd3b
BLAKE2b-512	512 bit	2013	a8add4bdddfd93e4877d2746e62817b116364a1fa7bc148d95090bc7333b3673f82401cf7aa2e4cb1ecd90296e3f14cb5413f8ed77be73045b13914cdcd6a918
BLAKE2s-256	256 bit	2013	606beeec743ccbeff6cbcdf5d5302aa855c256c29b88c8ed331ea1a6bf3c8812

Every digest in the table above is produced by the engines in this very page — tick all algorithms, click Sample, and compare. SHA-3, Keccak, RIPEMD-160 and BLAKE2 rows come from the self-hosted crypto-shared.js kernel used across this site’s crypto tools.

Which box should I trust for a download? The Verify box, with SHA-256 ticked — most publishers sign SHA-256 or SHA-512 today. The Identify box only names candidates; it never proves anything about your file.

Why is Keccak-256 in the list at all? Because Ethereum, Swarm and a few ledger systems standardized on the pre-standard padding. If you verify an Ethereum keccak256 you must use that row, not SHA3-256.

Can two different inputs share a digest? In theory, yes — infinitely many inputs map into a finite set of digests (pigeonhole principle). In practice, finding such a pair before the heat death of the universe is what “collision resistance” is about, and every algorithm above except MD5 and SHA-1 still stands.

Are hashes encryption? No. Encryption is reversible with a key; a hash is a one-way blender. Nothing on this page can be “decrypted” back into your text — and that is a feature, not a limitation.