Free Hash Generator
Generate MD5, SHA-1, SHA-256, SHA-384, SHA-512 hashes.
Result
What a Cryptographic Hash Function Actually Is
A cryptographic hash function takes an input of any size and produces a fixed-size output called a hash, digest or fingerprint. The same input always produces the same hash; even a single-bit change in the input produces a wildly different hash (the "avalanche effect"); and the function is computationally infeasible to invert, given a hash, you cannot practically find the input that produced it. Three resistance properties make a hash function "cryptographic": preimage resistance (given a hash h, infeasible to find any input m such that hash(m) = h), second-preimage resistance (given m1, infeasible to find a different m2 with the same hash), and collision resistance (infeasible to find any two distinct inputs with the same hash). A hash that loses collision resistance can still be safe for some uses (file integrity) but unsafe for others (digital signatures). MD5 and SHA-1 are in exactly that bucket: collision-broken but preimage-resistant.
A Short History of MD5, SHA-1, SHA-2 and SHA-3
MD2 / MD4 / MD5 are the work of Ron Rivest at MIT and RSA Data Security. MD2 was published in 1989; MD4 in 1990; MD5 was published in 1991 and standardised as RFC 1321 in April 1992. MD5 was the dominant hash for a decade, the default for download checksums, password storage, file deduplication and content-addressable systems. The first warning shot landed in 1995 when Hans Dobbertin published a full-round collision attack on MD4, MD5's predecessor; the first practical full-MD5 collision arrived in August 2004 when Wang and Yu announced two colliding 128-byte messages; Vlastimil Klima sped up MD5 collision-finding from hours to seconds on commodity hardware in 2006. Marc Stevens, working with researchers at TU Eindhoven and EPFL, demonstrated a chosen-prefix MD5 collision at 25C3 in December 2008 by producing a forged RapidSSL CA certificate. By the time of the Flame malware in 2012 (which used an MD5 collision to forge Microsoft Update certificates) MD5 was thoroughly broken for any security-sensitive use.
SHA ("Secure Hash Algorithm") is a family from the U.S. National Security Agency. SHA-0 was published as FIPS 180 in May 1993 and withdrawn within a year for unspecified design flaws. SHA-1 followed as FIPS 180-1 in April 1995, with a single-bit change to the message schedule that the NSA never publicly explained. SHA-1 became the default hash of the late 1990s and 2000s, used by Git for commit hashes, by SSL/TLS certificates, by virtually every signature scheme. The first theoretical collision attack came in 2005 (Wang, Yin, Yu); a freestart collision in 2015 (Stevens, Karpman, Peyrin); and the first full SHA-1 collision shipped on 23 February 2017 as "SHAttered" (Stevens, Bursztein, Karpman, Albertini, Markov), which produced two different PDF files with the same SHA-1 hash. By January 2020 the "SHA-1 is a Shambles" chosen-prefix attack (Leurent and Peyrin, total cost roughly USD 45,000 of GPU rental) made certificate-grade forgery affordable, accelerating the SHA-256 transition that the Git project had already begun planning in 2018. SHA-1 is now formally deprecated by NIST for digital signatures and certificates.
SHA-2 is the family that replaced SHA-1: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256, published as FIPS 180-2 in August 2002. SHA-2 was a defensive design (bigger output sizes, more rounds, larger internal state) and twenty-three years later it remains unbroken. SHA-256 is the modern default for digital signatures, certificates, JWT, Bitcoin block hashes, content-addressable storage, and most file integrity verification. SHA-3 is a fundamentally different design (the Keccak sponge construction by Bertoni, Daemen, Peeters and Van Assche) selected through a five-year NIST competition that opened in 2007 and was won by Keccak in October 2012; published as FIPS 202 in August 2015. SHA-3 is not a replacement for SHA-2 (SHA-2 is still secure); it's a defence-in-depth alternative with a completely different internal structure, so a future cryptanalytic break of SHA-2 wouldn't necessarily affect SHA-3. This tool emits SHA-1, SHA-256, SHA-384 and SHA-512 (the Web Crypto API supported set) plus MD5 (via a JavaScript implementation, since the Web Crypto API deliberately omits MD5).
Algorithm Comparison
| Algorithm | Output | Status (2026) |
|---|---|---|
| MD5 | 128-bit (32 hex chars) | Collision-broken; OK for non-security checksums and deduplication; never for signatures or passwords |
| SHA-1 | 160-bit (40 hex chars) | Collision-broken (SHAttered 2017, Shambles 2020); deprecated for new signatures; legacy Git use |
| SHA-256 | 256-bit (64 hex chars) | Secure; the modern default for everything |
| SHA-384 | 384-bit (96 hex chars) | Secure; faster than SHA-512 on 32-bit hardware while keeping 192-bit security |
| SHA-512 | 512-bit (128 hex chars) | Secure; preferred for high-throughput hashing on 64-bit hardware (Linux kernel, modern crypto libs) |
Where Cryptographic Hashes Show Up
- File integrity / checksums. Linux distribution mirrors publish SHA-256 (and historically MD5/SHA-1) hashes alongside ISO downloads; the user computes the hash of the downloaded file and compares to the published value. A mismatch means the download was corrupted or tampered with.
shasum,sha256sumandmd5sumare the standard Unix tools. - Password storage, but NEVER as a plain hash. Storing
SHA-256(password)directly is dangerous because rainbow tables (precomputed (password → hash) maps) make plain-hash passwords reversible in milliseconds. The right pattern is a password-hashing function (KDF) with a per-user salt and a tunable work factor: Argon2id (RFC 9106, 2021, the modern recommendation), scrypt (RFC 7914, Percival 2009), or bcrypt (Provos and Mazières, USENIX 1999). All three combine a salt (so identical passwords produce different stored hashes) with a deliberately expensive computation (so brute-force attacks are throttled by hardware cost). This tool computes raw hashes, useful for many things, but not appropriate for password storage on its own. - Digital signatures. Sign the hash, not the data, the data is too long to sign efficiently. RSA, DSA, ECDSA and EdDSA all sign a hash of the message. The hash function used must be collision-resistant (otherwise an attacker can substitute a colliding message); this is exactly why MD5 and SHA-1 are deprecated for signatures.
- Git's content-addressable storage. Every Git object (blob, tree, commit, tag) is identified by the SHA-1 of its content. Linus Torvalds's design choice from 2005 is now in the middle of a multi-year transition to SHA-256, driven by SHA-1's collision break. Git for Windows and core Git both ship SHA-256 support; production migration is gradual.
- Bitcoin and Ethereum. Bitcoin uses double-SHA-256 for block hashes and transaction IDs (the hash function dominates Bitcoin mining cost, ASICs exist solely to compute SHA-256 fast). Ethereum uses Keccak-256 (the original Keccak before NIST standardisation tweaks; sometimes called "SHA-3 minus the padding change").
- JWT signature verification. JSON Web Tokens are typically signed with HMAC-SHA-256 (algorithm name "HS256" in the JWT spec) or with RSA/ECDSA over a SHA-256 hash. The signature lets the receiver verify the token came from the issuer and hasn't been tampered with.
- Subresource Integrity (SRI). The
integrity="sha256-..."attribute on<script>and<link>tags lets browsers verify that a CDN-hosted script hasn't been modified before executing it, a defence against compromised CDNs. - API request signing. AWS Signature Version 4 uses HMAC-SHA-256 to sign every API request with the user's secret access key. This authenticates the request without sending the secret over the wire and prevents replay attacks via timestamp.
Collision Break vs Preimage Break, Why MD5 Is Still Used
A common confusion: if MD5 is "broken," why does md5sum still ship on every Linux distro? The answer is the distinction between collision resistance (broken in MD5) and preimage resistance (still intact in MD5). A collision attack lets an attacker construct two different inputs with the same hash; this matters for digital signatures (where an attacker can craft a colliding pair, get one signed, and substitute the other) and for any application where the hash function is supposed to bind a specific input. A preimage attack, by contrast, would let an attacker recover the original input from a hash, this is what would actually break a download checksum, a password hash or a content-addressed identifier. Preimage resistance for MD5 has not been broken; the best published preimage attacks remain close to the theoretical 2128 bound, computationally infeasible on any hardware that exists or is expected to exist. So MD5 (and SHA-1) remain legitimate for: file integrity verification when you trust the source of the published hash (an attacker who can substitute the file can presumably also substitute the hash, so the threat model is "accidental corruption" not "deliberate tampering"); cache keys and deduplication where you control both ends; HMAC constructions (HMAC-MD5 is still secure because HMAC's structure is robust against MD5's collision weakness, though HMAC-SHA-256 is preferred for new code). Where MD5 must be replaced: digital signatures, certificate hashes, anywhere an attacker can craft input.
The Web Crypto API, and the Deliberate MD5 Omission
Modern browsers expose hashing through crypto.subtle.digest(algorithm, data), an asynchronous function that returns the hash as an ArrayBuffer. Supported algorithms: SHA-1, SHA-256, SHA-384, SHA-512. Notice what's not in that list: MD5 is deliberately omitted. The W3C Web Crypto Working Group made the explicit decision to leave MD5 out, reasoning that any MD5 use in a browser was either legacy (better handled with a polyfill) or wrong (and shouldn't be made easy). This tool's MD5 support comes from a small JavaScript implementation (~10 KB) bundled in the page; everything else (SHA-1, SHA-256, SHA-384, SHA-512, plus all HMAC variants) routes through Web Crypto for native-speed processing. The Web Crypto API is only available in secure contexts (HTTPS or localhost), opening this tool over plain HTTP would silently disable the SHA hashing.
Output Formats: Hex, Base64, Base32
Hashes are binary by nature, a 256-bit hash is 32 bytes of opaque data. To display or transport them, they're encoded as text. Hex (Base16) is the most common encoding: each byte becomes two hex characters, so SHA-256 output is 64 hex characters. Universal, readable, doubles the size. Base64 packs bytes more densely (3 bytes → 4 characters); SHA-256 in Base64 is 44 characters (with padding) or 43 (without). Used in JWT (the signature is Base64URL-encoded), in integrity SRI attributes, and anywhere compactness matters. Base32 (RFC 4648) uses 32 characters that exclude visually ambiguous ones (no 0/O, 1/I/L distinction); used in TOTP secret keys, ULIDs, and onion addresses. This tool emits hex by default, the universal format that every other tool understands.
HMAC, Keyed Hashing for Authentication
HMAC (Hash-based Message Authentication Code) is a construction defined in RFC 2104 (Krawczyk, Bellare, Canetti, February 1997) that turns any cryptographic hash function into a keyed authentication code. The construction is HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)), where K' is a derived key from the secret K, and opad/ipad are fixed XOR pads. The structure is provably secure as long as the underlying hash is, and notably remains secure even when the underlying hash has weak collision resistance (which is why HMAC-MD5 is still considered safe, and why HMAC-SHA1 is OK in TLS even after SHA-1's collision break). HMAC has three main uses: API request signing (AWS Signature v4, GitHub webhooks, Stripe webhooks), where the receiver verifies the request came from the holder of the secret; JWT integrity (HS256 = HMAC-SHA-256); and password-based key derivation (PBKDF2 uses HMAC internally). This tool's HMAC mode takes a secret key and produces the HMAC of the input under that key.
Honest Scope: What This Tool Is and Isn't For
This tool computes raw cryptographic hashes of input text or files. Useful for: verifying file downloads against published checksums, generating content-addressable identifiers, computing HMAC values for API debugging, comparing the integrity of two copies of a file, and learning what specific inputs hash to. Not useful for: password storage (use a real password-hashing function like Argon2id, scrypt or bcrypt with proper salt and work factor); reversing hashes (which is the entire point of hash functions and not possible by design); or generating SHA-3 / Keccak hashes (this tool currently emits SHA-1, SHA-256, SHA-384 and SHA-512 from the SHA-2 family, plus MD5, SHA-3 is on the future-feature list); generating BLAKE2 or BLAKE3 hashes. For BLAKE3 (the modern high-throughput hash for content-addressable storage), use the dedicated CLI; for password storage, use your application's bcrypt/scrypt/Argon2id library directly.
Privacy: Why Browser-Only Matters Here
Hashing a file on a server requires uploading the file. For ordinary download verification this is moot, you already trust the source. For hashing internal documents, scanned IDs, screenshots of work-in-progress UI, or any file you wouldn't want copied onto a stranger's hard drive, server-side hashing is a leak. This tool reads the file directly in your browser using the File API and hashes it locally, nothing leaves your device. Verify by opening DevTools' Network tab while you click Hash, or take the page offline (airplane mode) after it loads and confirm the tool still works. The Web Crypto API requires HTTPS but does not require network access at runtime.
Frequently Asked Questions
If MD5 is broken, why is it still used?
MD5's collision resistance is broken (an attacker can construct two different inputs with the same hash) but its preimage resistance is intact (you cannot recover an input from a hash). For file-integrity checking against accidental corruption, deduplication, cache keys and HMAC constructions, MD5 is still legitimate. For digital signatures, certificates, password storage or any application where an attacker can craft inputs, MD5 must not be used, SHA-256 is the safe modern default.
Can I reverse a hash to get the original text?
No, that's the entire point of a hash function. The math is one-way by design, and even the best published preimage attacks against MD5 (the most-broken algorithm here) remain close to the theoretical 2128 bound, computationally infeasible on any hardware that exists or is likely to exist. The way attackers "reverse" hashes in practice is through rainbow tables: precomputed maps of common passwords to their hashes, which only work against unsalted hashes of weak passwords. Salting the hash (adding random per-input data before hashing) defeats rainbow tables completely; this is why password storage uses salted KDFs (Argon2id, bcrypt, scrypt) rather than raw hashes.
Should I use this to hash my passwords?
No. Raw cryptographic hashes (even SHA-512) are dangerously fast for password storage, modern GPUs can compute hundreds of billions of SHA-256 hashes per second, which means rainbow tables and brute-force attacks against password hashes are cheap. Use a real password-hashing function: Argon2id (RFC 9106, modern recommendation, winner of the 2015 Password Hashing Competition); scrypt (RFC 7914); or bcrypt (Provos and Mazières, USENIX 1999). All three combine a per-user salt with a tunable work factor that makes brute-force attacks expensive. Most server frameworks (Django, Rails, Spring, Laravel) include one of these by default; never roll your own.
What's the difference between SHA-256 and SHA-3?
SHA-256 is part of the SHA-2 family (FIPS 180-2, August 2002) (Merkle-Damgård construction, designed by NSA. SHA-3 (FIPS 202, August 2015) is the Keccak family) sponge construction, designed by Bertoni, Daemen, Peeters and Van Assche, selected through a public NIST competition. SHA-3 is not a replacement for SHA-2 (SHA-2 is still secure); it's a defence-in-depth alternative with a fundamentally different internal structure, so a hypothetical future break of SHA-2 wouldn't necessarily affect SHA-3. For new applications in 2026, SHA-256 is still the right default; SHA-3 is increasingly used in Ethereum and post-quantum schemes. This tool currently supports SHA-2 (SHA-1 / 256 / 384 / 512); SHA-3 is on the future-feature list.
What is HMAC and when do I need it?
HMAC (Hash-based Message Authentication Code, RFC 2104, 1997) is a keyed-hash construction that proves a message was created by someone who knows a shared secret. You need it whenever you're verifying that a request came from the right party, verifying GitHub webhook signatures (the secret is the webhook's signing key), Stripe webhook signatures, AWS API request signatures (Signature v4 is HMAC-SHA-256), or JWT signatures (HS256 = HMAC-SHA-256). HMAC remains secure even when the underlying hash has weak collision resistance, which is why HMAC-MD5 is still considered safe, though HMAC-SHA-256 is the modern default for new code.
Is my file uploaded when I hash it?
No. The file is read directly in your browser using the File API and hashed locally (via the Web Crypto API for SHA family algorithms, via a small JavaScript implementation for MD5. Nothing crosses the network) verify in DevTools' Network tab while you compute, or take the page offline after it loads. Safe for hashing internal documents, scanned IDs, work-in-progress UI screenshots or any file you wouldn't want copied onto a stranger's hard drive.