A hash function takes any input — a short word, a password, an entire file's worth of bytes — and deterministically produces a fixed-length string of characters that uniquely represents that input. This tool computes five of the most common hash algorithms for whatever text you enter, live, entirely inside your browser.
What a hash actually is, and what it's for
The defining properties of a cryptographic hash function are what make it useful: the same input always produces exactly the same output (determinism), a tiny change to the input — even a single character — produces a completely different, unrelated-looking output (the avalanche effect), the output is always a fixed length regardless of how large or small the input is, and critically, there's no practical way to work backward from the hash to recover the original input. These properties combine to make hashing useful for an entire category of problems that have nothing to do with encryption despite often being mentioned in the same breath: verifying that a file hasn't been corrupted or tampered with, storing passwords without ever storing the actual password, and generating a compact, fixed-size fingerprint for data that would otherwise be too large to compare directly.
It's worth being precise about a common point of confusion: hashing is not encryption, and the two solve fundamentally different problems. Encryption is explicitly designed to be reversible — given the right key, ciphertext converts back into the original plaintext, because the whole point of encryption is that an authorized party can eventually recover the original message. Hashing has no equivalent reverse operation at all, by design; a hash is meant to be a one-way fingerprint, not a way to disguise-and-later-recover data. If a tool claims to "decrypt" a hash, it's either doing something else entirely (like looking up the hash in a precomputed table of common inputs — a "rainbow table" — which only works for short, guessable inputs) or misusing the term.
Why this tool computes five different algorithms at once
MD5, SHA-1, SHA-256, SHA-384, and SHA-512 all do the same fundamental job — deterministically fingerprint an input — but they differ in output length, computational cost, and, most importantly, their current cryptographic security status. Which one you actually need in a given situation is almost always dictated by an external constraint, not personal preference: a piece of legacy software that only reports MD5 checksums, a security tool that expects SHA-256, a download page that publishes a SHA-512 hash for verification. Generating all five at once, rather than making you pick one algorithm up front and switch tools if it turns out to be the wrong one, means you can immediately compare against whichever hash format the other system happens to have provided.
MD5 and SHA-1: still common, no longer secure
Both of these algorithms remain in widespread practical use despite being formally broken from a security standpoint, and understanding why requires separating "broken for security purposes" from "useless for every purpose." MD5's core vulnerability is that researchers demonstrated practical hash collisions — two different pieces of input that produce an identical MD5 output — meaning it's possible to construct a malicious file that hashes identically to a legitimate one, which completely defeats any use of MD5 as proof that a file hasn't been tampered with. SHA-1 suffered the same fate more recently and more dramatically: in 2017, researchers at Google and CWI Amsterdam publicly demonstrated the "SHAttered" attack, producing two distinct PDF files that share an identical SHA-1 hash, and published proof-of-concept tools showing the attack was practically achievable, not just theoretically possible. Neither algorithm should be used anywhere hash collisions represent a genuine security risk — password storage, digital signatures, certificate validation, or verifying a file hasn't been maliciously tampered with. But both remain genuinely useful for detecting accidental corruption — a file that got truncated during a download, a copy operation that silently dropped a byte — where nobody is deliberately trying to construct a colliding input, and the practical odds of accidental data corruption happening to produce a matching hash by pure chance remain astronomically low even for a "broken" algorithm. This is exactly why MD5 checksums are still common in older tooling, caching systems, and file-integrity spot-checks, even though no security professional would recommend it for anything adversarial.
SHA-256 and beyond: the current practical standard
SHA-256, part of the SHA-2 family designed by the NSA and published by NIST in 2001, is the algorithm most modern systems default to today, and for good reason — it has no known practical collision or preimage attacks as of today, its 256-bit output provides a very large security margin against brute-force attacks, and it's fast enough in practice (especially with hardware acceleration, which most modern CPUs include specifically for SHA-256) to use at scale without a meaningful performance cost. It's the algorithm behind Bitcoin's proof-of-work, the algorithm most TLS certificates are signed with today, and the default choice for most modern software's file-integrity checksums. SHA-384 and SHA-512, both part of the same SHA-2 family, offer a longer output (384 and 512 bits respectively) and, correspondingly, an even wider theoretical security margin — useful in specific contexts that call for extra headroom against future cryptanalytic advances, though for the overwhelming majority of everyday hashing needs, SHA-256 already provides more than sufficient security margin for the foreseeable future.
What hashing is genuinely useful for, day to day
Verifying a downloaded file matches what the publisher intended — comparing a computed hash of the downloaded file against a hash the publisher listed on their site catches both accidental corruption during download and, to the extent the publishing channel itself is trusted, deliberate tampering somewhere in between. Generating a stable, fixed-size identifier or cache key from a longer piece of content, so two pieces of content can be quickly compared or looked up by their hash rather than comparing the full content directly every time. Checking whether two pieces of text or two files are identical without visually comparing them character by character — if their hashes match, the contents are (for all practical purposes) identical; if the hashes differ even slightly, something about the content differs too, even if it's not obvious at a glance.
What hashing alone does not do
A raw, unsalted hash of a password is not, by itself, a secure way to store that password — real authentication systems add a random "salt" unique to each password before hashing, specifically to defeat precomputed rainbow-table attacks, and typically use a purpose-built, deliberately slow password-hashing algorithm (like bcrypt, scrypt, or Argon2) rather than a general-purpose fast hash like SHA-256, precisely because a fast hash makes brute-forcing large numbers of password guesses too cheap for an attacker. This tool computes general-purpose hashes for verification, identification, and integrity-checking use cases — it is not, and shouldn't be treated as, a substitute for a proper password-hashing library in any system that actually authenticates users.
Matching hashes tell you two pieces of content are identical — they don't, by themselves, tell you the content came from who it claims to. If an attacker can modify both a file and the hash published alongside it (for instance, by compromising the same download page), a hash comparison alone won't catch that. Genuine authenticity verification needs a cryptographic signature checked against a trusted public key, which is a related but distinct mechanism from hashing alone.