Hash Generator
MD5, SHA-1, SHA-256, SHA-384 and SHA-512 from one input, computed in your browser.
Five digests from one input. Nothing is uploaded — hashing happens in the page, and the input never leaves it.
When you need this
- You downloaded a file and want to check the published checksum before you run it.
- You are comparing two builds and need the same digest algorithm the release notes used.
- A legacy system stores MD5 hashes and you need to reproduce one to compare.
- You are writing a test fixture and need a known digest for a known string.
Why other hash generators fall short
Many hash tools still lead with MD5 and never say that it is broken for security. Using MD5 as a checksum is fine; using it for a password is not, and the difference deserves a label rather than a footnote.
Tools that hash the textarea's characters without stating the encoding give a different answer than sha256sum for anything with non-ASCII characters or Windows line endings.
Online hash sites that compute on their server see your input in plain text. For a checksum that is usually fine; for a token or a key it is not, and you cannot tell which case you are in from the outside.
Frequently asked questions
Which algorithm should I use?
SHA-256 unless something external forces another choice. For file checksums SHA-256 is the default everywhere; SHA-1 and MD5 appear when a legacy system already uses them. Neither is acceptable for passwords — use a password hash (bcrypt, scrypt, Argon2) for that, never a general-purpose digest.
Can MD5 or SHA-256 be decrypted?
No. A hash is one-way by design: the 128 bits of an MD5 digest cannot be run backwards into the input, and no tool — this one included — has a decrypt button that really decrypts. What sites advertising "MD5 decryption" do is look your hash up in a table of precomputed digests (a rainbow table, or a leaked password list) and hand back the input that produced it, if that input is already in the table. That works exactly for the passwords weak enough to have appeared there before, which is the reason a password should never be stored as a plain MD5 or SHA-256 digest in the first place.
Why does my computed hash differ from sha256sum?
Almost always line endings or encoding. sha256sum hashes the file's bytes, including CRLF if the file has them; pasting the same text into a browser gives LF-only bytes, because the text is hashed as UTF-8 exactly as the textarea holds it. A BOM at the start also changes the result, invisibly — three bytes you cannot see in any editor are still part of the digest. Paste a file's bytes (drop the file here) rather than its text when you need to match a published checksum.
Is this different from hashing a file?
The algorithm is identical, the input is not. Dropping a file here hashes its bytes exactly as stored, which is what you want for a checksum. Pasting its text hashes the UTF-8 encoding of the characters, which is what you want for a string.
Can I use this to hash a password?
You can compute it, but you should not store the result. A fast general-purpose digest like SHA-256 lets an attacker try billions of guesses per second. Password storage needs a deliberately slow function with a per-user salt.