MD5 and SHA Hash Generator
Five digests at once for text or a file, output as hex or Base64, computed locally so the file never leaves your machine.
Checking a download against the checksum the vendor published, confirming two files are byte-identical, deriving a fixed-length key for a cache or an upload part - all of it is routine digest work. Picking algorithms by hand, switching case and copying results one at a time is slow, and a single transposed character costs far more time to track down afterwards.
Type text or choose a file and the page reports MD5, SHA-1, SHA-256, SHA-384 and SHA-512 together, in either hexadecimal case or Base64. Text is converted to bytes with TextEncoder, files are read as binary, and nothing is uploaded, so a large archive is digested without a single network request. The exact value is what both sides must compare: a hash computed over a different encoding, or over a file with an extra newline, will never match.
Collision attacks: why MD5 and SHA-1 are out for security
MD5 collisions have been practical for years - an ordinary machine can construct two different files with the same digest in seconds - and SHA-1 fell in 2017 with the SHAttered attack. A collision lets someone prepare a file whose hash matches the one you are checking, which is fatal for digital signatures, certificates and software distribution. Anything security-facing should use SHA-256 or above, or SHA-3. For purposes that only need to catch accidental corruption - verifying that a download completed, deduplicating content, building a cache key - MD5 remains fast, universally supported and adequate.
Digests are one-way, and salting is what slows attackers down
A digest compresses any input to a fixed length and destroys information in the process, so there is no inverse function to compute. Sites that claim to decrypt MD5 are either looking the value up in a precomputed rainbow table or brute-forcing a dictionary, and both only work against common passwords. A salt - a random string stored per user and mixed into the input - makes identical passwords produce different digests and renders rainbow tables useless. Iterating the function many times, or using a purpose-built slow hash such as bcrypt, scrypt or Argon2, multiplies the cost of every guess.
Hashing in the browser does not replace salting on the server
Computing a hash client-side feels safer than it is: the runtime and the code both belong to the user. A salt shipped in the bundle can be read out of it, and the hashing logic itself can be rewritten, so an attacker who eventually dumps the database still gets values to crack offline. The division that holds up is to use client-side hashing for integrity checks, deduplication and cache keys, and to leave password storage to the server, where each password gets its own random salt and a deliberately slow hash, with transport encryption on top. Client-side hashing is a convenience, not a control.
Frequently asked questions
- Is MD5 still safe?
- Not for any security purpose. Collisions can be produced in seconds, which rules it out for signatures, certificates and password storage. For checksums where the threat is a truncated download rather than a forger, MD5 is still common, fast and well supported.
- Can MD5 be reversed back to the original text?
- No. It is a lossy compression, and the information needed to reconstruct the input is gone. What "MD5 decrypt" services return comes from rainbow tables or dictionaries and covers only weak, common passwords; a hash with a random salt is in no table.
- Should file verification use MD5 or SHA-256?
- SHA-256 when the concern is deliberate tampering or a substituted file; MD5 is enough, and faster, when you are only confirming that a download arrived intact. Compare against the value the publisher actually printed, and never compare an MD5 against a SHA-256 - they are different values for the same bytes.
- Will the same text always produce the same hash?
- Yes. A digest is deterministic: same input, same algorithm, same encoding, same output, every time. When two sides disagree it is almost always an encoding difference such as UTF-8 against GBK, an extra newline or a BOM, or a salt mixed into one of the inputs.