Hash Generator — SHA-256, SHA-1 and MD5
Generate a hash for text or a file. All algorithms compute at once, so you can copy whichever you need, and you can paste a published checksum to verify a download matches — without uploading the file anywhere.
- Free, no sign-up
- Runs in your browser
- Nothing uploaded
- Updated Sep 2026
Drop a file here, or click to choose one
The file is read in your browser and never uploaded
At a glance
- Algorithms
- SHA-256, SHA-384, SHA-512, SHA-1, MD5
- Input
- Text or any file
- Verify
- Paste a known checksum to compare
- Use SHA-256
- For anything where security matters
- Never
- Hash passwords with these — use bcrypt, scrypt or Argon2
- Processing
- Entirely client-side
Which algorithm to use
SHA-256 is the default answer. It is secure, fast, universally supported and what you should reach for unless a specific system requires something else. SHA-384 and SHA-512 are also secure; on 64-bit hardware SHA-512 is often faster than SHA-256, though the longer digest is rarely worth the extra characters.
SHA-1 is broken for security purposes. A practical collision was demonstrated in 2017, and producing one is now inexpensive. It survives in Git commit IDs and some legacy protocols where the threat model does not depend on collision resistance, but it must not be used for signatures, certificates or anything where an attacker benefits from two inputs hashing alike.
MD5 is thoroughly broken — collisions can be generated in seconds on a laptop. It has exactly one legitimate remaining use: detecting accidental corruption, such as checking a file downloaded intact. It is offered here because published checksums still use it, not because it should be chosen for anything new.
The SHA family here is computed with the browser's built-in Web Crypto API, which is a native implementation. MD5 has no Web Crypto support and is implemented in JavaScript, which is another small reason to prefer SHA-256.
Never hash passwords with these
This is the most consequential misuse of general-purpose hash functions, and it appears in production systems regularly.
SHA-256 is designed to be fast. That is exactly wrong for passwords. Modern hardware computes billions of SHA-256 hashes per second, so a leaked database of SHA-256 password hashes can be attacked at enormous speed. Adding a salt prevents precomputed rainbow tables but does nothing about raw speed.
Password hashing needs a function deliberately designed to be slow and memory-hard: Argon2id (the current recommendation), bcrypt (mature, widely available, still fine) or scrypt. These have a tunable work factor, so you can keep them expensive as hardware improves. Every mainstream language has a library; none of this needs implementing by hand.
Where SHA-256 is right: file integrity, content addressing, deduplication, digital signatures, HMAC message authentication, and blockchain-style structures. All cases where speed is a feature and the input is not a secret guessable by brute force.
Verifying a download
The most common everyday use of a hash is confirming a downloaded file arrived intact and unmodified. The project publishes a checksum; you compute the hash of what you received; the two should match exactly.
Drop the file into this tool and paste the published checksum into the compare field. The comparison is case-insensitive and ignores surrounding whitespace, because published checksums come formatted in various ways. A match means the file is byte-identical to what was published.
One limitation worth understanding. If an attacker can replace the file on a download server, they can usually replace the checksum on the same page — so matching a checksum served from the same place as the file proves little about tampering. It reliably proves the download was not corrupted in transit, which is the common failure. For genuine tamper evidence you need a signature verified against a key obtained independently, which is what GPG signing on release artefacts is for.
The file is read locally with the browser's FileReader and hashed in the page — nothing is uploaded, which also means you can verify large or confidential files without them leaving your machine.
How to use the Hash Generator
-
Enter text or choose a file
Text hashes as you type. Files are read locally and hashed in the page — nothing is uploaded.
-
Read the digests
Every algorithm is computed at once. Copy whichever you need with the button beside it.
-
Compare against a known checksum
Paste a published checksum into the compare field. Matching is case-insensitive and ignores whitespace.
-
Pick the right algorithm for the job
SHA-256 for anything security-related. MD5 only for detecting accidental corruption. Neither for passwords.
Frequently asked questions
Is my data uploaded to hash it?
No. The SHA algorithms use the browser's native Web Crypto API and MD5 runs in JavaScript, both inside your tab. Files are read with FileReader and never transmitted, so you can hash confidential documents safely.
Which hash algorithm should I use?
SHA-256 unless something specifically requires otherwise. It is secure, fast and universally supported. SHA-512 is equally secure and sometimes faster on 64-bit systems. Avoid SHA-1 and MD5 for anything where security matters.
Can I use SHA-256 for passwords?
No. It is designed to be fast, which is precisely wrong for passwords — an attacker with a leaked database can try billions of guesses per second. Use Argon2id, bcrypt or scrypt, which are deliberately slow and have a tunable work factor.
Is MD5 still safe for anything?
Only for detecting accidental corruption — confirming a file downloaded intact. Collisions can be generated in seconds, so it provides no protection against deliberate tampering. It is included here because published checksums still use it.
Can a hash be reversed?
Not mathematically — hashing is one-way. But short or common inputs can be found by brute force or by looking them up in precomputed tables, which is why hashing a password without a salt and a slow algorithm offers so little protection.
Why do two files with the same content hash differently?
The content is not identical at the byte level. Common causes are line endings (CRLF against LF), a trailing newline, a byte order mark, or different text encodings. Hashing operates on bytes, not on what the file looks like.