Hash Generator
Generate MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hash digests for text and files. All hashing runs locally in your browser.
Drag & drop a file or click to browse
Hash digests will appear here
Type text or drop a file to begin
TL;DR — pick the right algorithm
For anything security-related, use SHA-256 or SHA-512. MD5 and SHA-1 are cryptographically broken — practical collision attacks exist — so they are fine for non-security checksums but must never back signatures, certificates, or deduplication where an attacker controls the input. Hashing is one-way and is not encryption: there is no key and no "decrypt" step. And never store passwords with a plain hash of any kind — use a deliberately slow algorithm like bcrypt, scrypt, or Argon2 with a per-user salt.
Hash algorithm security status, at a glance
The single most common mistake with hashing is using a broken or unfit algorithm for the job. This table maps the common general-purpose hash functions to their digest size and their current real-world security status. "Broken" means a practical collision has been publicly demonstrated; "secure" reflects current consensus with no known practical attacks as of 2026.
| Algorithm | Output | Hex chars | Status |
|---|---|---|---|
MD5 | 128-bit | 32 | Broken — collisions trivial; checksums only |
SHA-1 | 160-bit | 40 | Broken — collision shown (2017); deprecated |
SHA-224 | 224-bit | 56 | Secure — SHA-2 family |
SHA-256 | 256-bit | 64 | Secure — current default; SHA-2 |
SHA-384 | 384-bit | 96 | Secure — truncated SHA-512 |
SHA-512 | 512-bit | 128 | Secure — SHA-2; fast on 64-bit CPUs |
SHA3-256 | 256-bit | 64 | Secure — Keccak; different design from SHA-2 |
bcrypt | ~184-bit | — | Password storage only — slow by design, salted |
scrypt | configurable | — | Password storage only — memory-hard, salted |
Argon2id | configurable | — | Password storage only — 2015 PHC winner; recommended |
This tool computes MD5, SHA-1, SHA-256, SHA-384, and SHA-512. The other rows are listed so you can see where they fit — bcrypt, scrypt, and Argon2 are intentionally not general-purpose hashers and should be run server-side via a vetted library, never in a quick web tool.
Hashing is not encryption — and you cannot "decrypt" a hash
The most persistent misconception in this area is treating a hash as reversible. It is not. A hash function is one-way by design: it deliberately throws away information so that the original input cannot be reconstructed from the digest. There is no key, so there is nothing to "decrypt" — searching for an "MD5 decrypter" is really searching for a lookup database of pre-computed hashes.
Encryption is the opposite: it is reversible by design. With a key you can transform ciphertext back into the exact original plaintext. AES, ChaCha20, and RSA are encryption; SHA-256 and MD5 are not.
So why do sites appear to "crack" a hash? Because hashes are deterministic and unsalted hashes are public-knowledge for common inputs. If you hash the word password, the MD5 digest is always 5f4dcc3b5aa765d61d8327deb882cf99. A reverse-lookup service simply pre-hashed billions of common strings and stores the input alongside the digest. It never reversed the math — it looked the answer up in a table. This is exactly why salting and slow password hashes exist.
Why you must never store passwords with a plain hash
General-purpose hashes like SHA-256 are built to be fast — that is a feature for checksums and a fatal flaw for passwords. Modern hardware can compute billions of SHA-256 hashes per second on a single GPU, so if your password table leaks, an attacker can brute-force common passwords almost instantly. Three defenses, used together, address this:
- A unique per-user salt. A random value stored alongside each hash so that two users with the same password get different digests. This defeats precomputed rainbow tables and forces an attacker to crack every account separately.
- A deliberately slow, tunable algorithm. bcrypt, scrypt, and Argon2 add a cost/work factor you can raise over time as hardware gets faster, keeping each guess expensive.
- Memory-hardness (scrypt, Argon2). Forcing each guess to use significant RAM blunts the massive parallelism of GPUs and custom ASICs that makes fast hashes so cheap to attack.
Current guidance from OWASP recommends Argon2id as the first choice for new applications, with scrypt and bcrypt as accepted alternatives. None of these should be run client-side in a web tool — password hashing belongs server-side with parameters tuned to your hardware. This generator is for checksums and integrity work, not for hashing real credentials.
Verifying a file download against a published checksum
The everyday legitimate use of this tool is integrity checking. A publisher lists a SHA-256 digest next to a download; you hash the file you received and compare. If the two strings match character-for-character, the file is bit-identical to what was published. The comparison is case-insensitive — hex is hex whether upper or lower.
# macOS / Linux shasum -a 256 ubuntu-24.04.iso # Windows (PowerShell) Get-FileHash ubuntu-24.04.iso -Algorithm SHA256
One important caveat: a matching checksum only proves the file is identical to the published one. It does not prove the publisher is trustworthy, because anyone who can replace the file can also replace the checksum on the same page. For real tamper protection, publishers sign their releases (for example with GPG or Sigstore) so the signature — not just the hash — can be verified against a known public key. Treat a bare checksum as a corruption check, not a security guarantee.
Hash questions people actually search for
Can I decrypt or reverse an MD5 or SHA-256 hash?
No. Hashing is one-way and is not encryption, so there is no key and no decrypt operation. So-called "hash decrypters" are reverse-lookup databases: they pre-computed the hashes of billions of common strings and simply look up the input that produced your digest. They cannot reverse the math — they only find matches for inputs that someone already hashed. A long, random, unique input will not be in any such table.
Is MD5 still safe to use in 2026?
MD5 is cryptographically broken — practical collision attacks (two different inputs producing the same digest) have been public for years, and chosen-prefix collisions make it dangerous wherever an attacker controls input. Never use it for digital signatures, certificates, password hashing, or security deduplication. It is still acceptable as a fast non-security checksum to detect accidental corruption, where no adversary is involved.
Why is SHA-1 deprecated if it is longer than MD5?
Digest length is not the same as security. In 2017 researchers demonstrated the first practical SHA-1 collision (the "SHAttered" attack), proving the algorithm's collision resistance was broken regardless of its 160-bit output. Browsers and certificate authorities had already begun phasing out SHA-1 certificates, and Git has since moved toward SHA-256. Use SHA-256 or stronger for anything security-relevant.
Should I use SHA-256 to hash user passwords?
No. SHA-256 is secure as a general-purpose hash but far too fast for password storage — attackers can try billions of guesses per second against a leaked table. Use a deliberately slow, salted password hashing algorithm instead: Argon2id is the current OWASP first choice, with scrypt and bcrypt as accepted alternatives. Run it server-side with a tuned work factor, never in a browser tool like this one.
Why do two different files sometimes have the same hash?
That is a collision. For a secure algorithm like SHA-256 a collision is computationally infeasible to find on purpose and astronomically unlikely by chance, so in practice it never happens. For broken algorithms like MD5 and SHA-1, attackers can deliberately craft two different inputs with the same digest — which is exactly why those algorithms must not be trusted for integrity against an adversary.
Is the text or file I hash here sent to a server?
No. The site is a static export with no backend. SHA hashes are computed with the browser's built-in Web Crypto API and MD5 in local JavaScript, so your input never leaves your machine. You can confirm this in DevTools → Network: generating a hash triggers zero outbound requests. Even so, treat any web tool as untrusted for live secrets and hash sensitive data with a local command-line tool instead.
Security disclaimer: This page is general educational information, not security or legal advice. Cryptographic recommendations change as new attacks are discovered — verify current guidance against authoritative sources such as NIST and OWASP before relying on any algorithm for a security-critical system. Do not hash production passwords or live secrets in any browser tool.