SHA Hash Generator

Why MD5 is not offered here

This question comes up often, because almost every online hash tool offers MD5. The answer is technical and precise: crypto.subtle.digest, the browser's built-in cryptography interface, implements only SHA-1, SHA-256, SHA-384 and SHA-512. MD5 appears nowhere in the specification, and that is a deliberate design decision rather than an oversight. Practical collision attacks on MD5 have been public since 2004: you can produce two different inputs with an identical digest in seconds. The standard refused to put a broken algorithm on the platform surface.

The only way to add MD5 to this page would be to ship a hand-rolled JavaScript implementation. That means both unnecessary bundle weight and the wrong message. If you have a legitimate reason to compute an MD5, such as verifying a legacy file checksum, reach for md5sum or openssl dgst -md5 on the command line. If you are designing a new system, MD5 is not the right answer at any layer of it.

Algorithms and digest lengths

SHA-1 is on the list because legitimate uses for it remain. Git object identifiers, legacy file inventories and checksums intended to catch accidental corruption all qualify. The distinction is this: SHA-1 is still good at catching random damage, but not at resisting a deliberate attacker. The SHAttered research published in 2017 produced two valid PDFs sharing one SHA-1 digest. It therefore has no place anywhere a signature, certificate or proof of integrity is required, and the tool labels it accordingly in the interface.

Hashing is not encryption

The most common misconception arrives as "how do I decrypt this hash". You cannot. A hash function is one-way: it produces a fixed-length output no matter how long the input was, and information is irreversibly discarded along the way. A ten megabyte file collapses to a 64-character SHA-256 digest, and reversing that is not mathematically possible.

Sites advertised as an "MD5 decrypter" or a "SHA-1 cracker" perform no reversal at all. They look the digest up in enormous precomputed tables. If your input was a common password or a short word it will be in the table; if it was random text it will not. That says the input was guessable, not that the algorithm was broken.

SHA-256 is the wrong tool for passwords

The SHA family was designed to be fast. That is exactly the property you want for verifying a file, and exactly the property you do not want for storing a password. An ordinary graphics card computes billions of SHA-256 digests per second, so weak passwords in a leaked table fall within minutes. The correct answer is a password hashing function that is deliberately slow and memory-hungry.

1// WRONG: being fast works in the attacker's favour2const digest = await crypto.subtle.digest('SHA-256', utf8('mypassword'));3 4// RIGHT: server-side, with a salt and a cost parameter5import { hash, verify } from '@node-rs/argon2';6 7const stored = await hash('mypassword', {8  memoryCost: 19456, // KiB9  timeCost: 2,10  parallelism: 1,11});12// $argon2id$v=19$m=19456,t=2,p=1$<salt>$<digest>13 14await verify(stored, submittedPassword); // true / false

Why your hash does not match

When two parties believe they hashed the same text and get different results, the cause is almost always at the byte level. A hash function sees bytes, not characters, so encoding and line-ending differences land directly in the output. This tool always encodes input as UTF-8 and offers line-ending normalisation as a separate, explicit option.

1// Line endings: Windows CRLF and Unix LF are different bytes2sha256('a\n');   // 87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c73sha256('a\r\n'); // a different digest entirely4 5// Encoding: identical-looking text can be different bytes6new TextEncoder().encode('ş');        // [0xC5, 0x9F]  UTF-8, two bytes7// ISO-8859-9 writes the same letter as the single byte [0xFE].8// Same letter, different bytes, different digest.9 10// An invisible BOM is part of the text too11sha256('hello') !== sha256('\uFEFFhello');