Hash Generator

What a hash function is and how it works

A hash function takes an input of any size — a single character, a paragraph, an entire file — and produces a fixed-size output called a hash, digest, or checksum. Internally, the algorithm processes the input in blocks, applying rounds of mathematical operations (bit shifting, XOR, substitution, compression) until everything is condensed into a final value of the size defined by the algorithm — 128 bits for MD5, 256 bits for SHA-256, for example. The result works as a fingerprint of the content: it identifies it in a practically unique way, without allowing the original input to be reconstructed from it.

One-way function: why a hash can't be reversed

"One-way" means computing the hash from the input is fast and trivial, but going the other way — recovering the input from the hash — is computationally infeasible. This isn't an implementation limitation: it's the algorithm's own design goal. Unlike a cipher, which exists precisely to be reversed with the right key, a hash function doesn't store the input at all, only a digest of it — there's no key, secret, or process that "decrypts" it. In practice, the only way to try to reverse a hash is to guess candidate inputs and recompute the hash of each one until finding a match (brute-force or dictionary attack) — infeasible once the input is long enough.

Hash, cryptography and encoding aren't the same thing

The three terms are often confused, but they solve different problems. Hash is one-way and keyless — it verifies integrity and content identity, never hides nor recovers the input. Cryptography (encryption) is two-way and depends on a key — it exists precisely so it can be reversed by whoever holds the right key (e.g. AES, RSA). Encoding (Base64, URL Encode) makes no claim to security at all — it's just a representation transformation for transport compatibility, trivially reversible by anyone, with no key whatsoever.

Determinism and the avalanche effect

Two properties make a hash reliable as a verification tool. Determinism guarantees that the same input, processed by the same algorithm, always produces exactly the same hash — without it, comparing two files or confirming a download wasn't corrupted would be impossible. The avalanche effect guarantees the opposite in the right direction: changing a single character in the input — even one extra space — flips, on average, half of the resulting hash's bits, producing a completely different value with no apparent relation to the original. That effect is what stops anyone from inferring anything about the input from similar-looking hashes, and what makes a hash sensitive enough to detect even the smallest accidental or deliberate change.

What a hash collision is

A collision happens when two different inputs produce exactly the same hash. Since the input can be of any size while the output always has a fixed size, collisions mathematically exist in every hash function — the space of possible inputs is infinite, the space of outputs isn't. What separates a secure algorithm from a broken one isn't the absence of collisions (impossible), but the computational cost of finding one on purpose: a good algorithm makes that search infeasible in practice. MD5 and SHA-1 no longer offer that guarantee — real collisions have already been demonstrated for both (MD5 since 2004, SHA-1 with the SHAttered attack in 2017) —, making them unsuitable for any scenario where someone malicious could forge a malicious file with the same hash as a legitimate one.

Choosing the right algorithm

MD5 (128 bits) and SHA-1 (160 bits) are fast and still show up in legacy systems, but their collision-resistance guarantees are broken — using them today only makes sense for non-adversarial checksums (accidental corruption, never deliberate attack) or compatibility with a system that can't be replaced. SHA-2 (SHA-256/SHA-512) is today's industry standard, with no known practical attack, and the right default choice for any new integrity or security need. SHA-3 uses an internal construction structurally different from SHA-2 (sponge, instead of Merkle–Damgård) — it isn't "better" security-wise today, but serves as an independent alternative when you want to diversify the algorithm in use. BLAKE2 delivers SHA-3-level security with performance superior to MD5 in software. BLAKE3, the newest of the family, goes further: it uses a Merkle tree internally, allowing the computation to be parallelized across multiple cores — today's fastest option for verifying integrity of large files. Rule of thumb: for any new security-relevant use, prefer SHA-256, SHA-3, or BLAKE3; never MD5 or SHA-1.

Real-world applications of hash functions

Integrity verification: download pages publish the SHA-256 hash of the official file so whoever downloaded it can confirm they received exactly that content. Comparison and deduplication: backup and storage systems compare hashes instead of comparing bytes one by one to decide whether two files are identical, keeping only one physical copy of duplicated content. Document fingerprinting: a hash works as a short signature of an entire document — any change alters the hash and exposes the difference. Digital signatures: for efficiency, the private key signs the document's hash, not the whole document. Versioning: Git identifies every commit, file, and directory tree by the hash of its own content (historically SHA-1, migrating to SHA-256) — two commits with the same content share the same identifier. Caching and CDNs: filenames using "cache busting" rely on the content's hash, making the cache expire on its own exactly when the file changes. Unique content identification: systems like IPFS address a file by its own hash instead of a path or URL. Blockchain: each block references the hash of the previous block, chaining the whole history together — altering an old block changes its hash and breaks the chain, making tampering detectable.

Hash is the wrong tool for passwords

MD5, SHA-1, and even SHA-256 were designed to be fast — and speed is exactly what an attacker wants when brute-forcing a password, since specialized hardware can compute billions of these hashes per second. Password storage requires the opposite: an algorithm deliberately slow and expensive to compute, so testing each guess costs real time and memory. The correct algorithms for that are Argon2id (winner of the Password Hashing Competition, OWASP's current first-choice recommendation), bcrypt (decades of proven use, with an adjustable cost factor), and scrypt (requires memory in addition to time, making an attack on dedicated hardware even more expensive). Never use MD5, SHA-1, or SHA-256 directly to store a password — none of the three was designed for that purpose, even though all three are perfectly secure for the uses they're actually meant for (integrity, checksums).

Frequently asked questions