Which hash algorithm should I use?

Use SHA-256 for new projects. MD5 and SHA-1 are cryptographically broken and should not be used for security.

Is MD5 still safe for checksums?

For non-security checksums (file deduplication), MD5 is fast and fine. Do not use it for passwords or signatures.

What is the result length?

MD5: 128 bits (32 hex chars). SHA-1: 160 bits (40 hex chars). SHA-256: 256 bits (64 hex chars).

Does this tool upload my data?

No. All hashing runs in your browser using Web Crypto or JavaScript. Nothing is sent to a server.

SHA-256 vs SHA-1 vs MD5: Differences and Which to Use

Updated September 28, 2026 • 6 min read

MD5 (RFC 1321) is a 128-bit digest (32 hex chars). SHA-1 (FIPS 180-4) is 160 bits (40 hex) and collision-broken (SHAttered, 2017). SHA-256 (also FIPS 180-4) is 256 bits (64 hex). crypto.subtle.digest computes SHA-256 and SHA-1 in a secure context; MD5 is JavaScript because SubtleCrypto has no MD5. These are unkeyed checksums, not HMAC, not bcrypt, and not a file verifier. Example: Hash returns ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad for ASCII abc. Encoding UTF-8 text as RFC 4648 §8 hex (foobar → 666F6F626172) is /base16/, not a digest. Hash does not call String.prototype.normalize. SHA-256 output of NFC é (U+00E9) is 4a99557e4033c3539de2eb65472017cad5f9557f7a0625a09f1c3f6e2ba69c4c. SHA-256 output of NFD é (e + U+0301) is bf12767b0f2a56b2190075bae8169f656e3ce8d6357d4aff184bc6c7ea48f9f6. Compose e + U+0301 to é (U+00E9) on /unicode-normalize/. Nothing is uploaded.

A digest length is not a security product. The three algorithms on the live hash generator map bytes to a fixed hex string. Collision resistance, a keyed MAC, and a password KDF are different jobs. This page names those jobs so the hex is not oversold. Encoding the letters of a string as RFC 4648 §8 hex is a different algorithm — that output is foobar → 666F6F626172 on /base16/.

Quick comparison

Algorithm	Output	Speed	Collision status	Use for
MD5	128 bits (32 hex)	Fastest	Broken (2004)	Non-security checksums only
SHA-1	160 bits (40 hex)	Fast	Broken (SHAttered, 2017)	Legacy fingerprints only
SHA-256	256 bits (64 hex)	Moderate	No known collisions	New projects, signatures

MD5 has had practical collision attacks since Wang and Yu demonstrated them in 2004. SHA-1 was broken by the SHAttered attack in 2017, which produced two different PDF files with identical hashes. SHA-256 remains the standard choice for new applications requiring collision resistance.

Three digest lengths

MD5: 128 bits, RFC 1321

Ron Rivest’s MD5 (IETF RFC 1321, 1992) outputs 128 bits — 32 hexadecimal characters. It processes 512-bit blocks. SubtleCrypto does not implement MD5, so Docify uses a JavaScript RFC 1321 routine. RFC 6151 (2011) replaces the original security considerations: MD5 is no longer acceptable where collision resistance is required, such as digital signatures. A non-adversarial checksum or cache key is a different use.

MD5("abc") = 900150983cd24fb0d6963f7d28e17f72

SHA-1: 160 bits, collision-broken

SHA-1 is specified in FIPS 180-4 (originally FIPS 180-1, 1995). The digest is 160 bits — 40 hex characters. NIST deprecated SHA-1 in 2011 and disallowed it for digital signatures at the end of 2013. In 2017, Stevens, Bursztein, Karpman, Albertini, and Markov (Google / CWI Amsterdam) published SHAttered: two different PDF files with the same SHA-1. NIST’s hash-function table lists SHA-1 collision resistance as below 80 bits. The live tool still offers SHA-1 so you can match a legacy fingerprint, and it labels that hex collision-broken.

SHA-1("abc") = a9993e364706816aba3e25717850c26c9cd0d89d

SHA-256: 256 bits, FIPS 180-4

SHA-256 is in the SHA-2 family in FIPS 180-4. The digest is 256 bits — 64 hex characters. NIST lists 128-bit collision resistance and 256-bit preimage resistance. No practical collision on the full 64-round function is published. That is not a promise that none will appear, and it is not SHA-3 (FIPS 202 / Keccak), SHA-224, SHA-384, or SHA-512 — those names are not on this site. crypto.subtle.digest("SHA-256") needs a secure context (HTTPS or localhost).

SHA-256("abc") = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

The sample on the live hash generator fills ASCII abc; clicking Hash writes that SHA-256 hex. SHA-1 of the same bytes is a9993e364706816aba3e25717850c26c9cd0d89d. MD5 of the same bytes is 900150983cd24fb0d6963f7d28e17f72.

Collision resistance is not a checksum

Wang & Yu, RFC 6151, SHAttered

Finding two different inputs with the same digest breaks collision resistance. Wang and Yu’s MD5 collisions (CRYPTO 2004 / EUROCRYPT 2005) made that practical for MD5. SHAttered did the same for SHA-1 with real PDFs. A checksum that only detects accidental bit flips can still use a broken hash. A signature, a certificate, or a commitment that assumes “same digest means same file” cannot. The generator does not look for collisions and does not claim a digest proves authenticity.

Zero-byte files vs empty text

The well-known empty-message SHA-256 is FIPS 180-4’s hash of zero bytes:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

SHA-1 of zero bytes is da39a3ee5e6b4b0d3255bfef95601890afd80709; MD5 is d41d8cd98f00b204e9800998ecf8427e. Docify hashes an empty file as those zero bytes. Empty text is rejected so a blank box is not mistaken for that test vector. Text is UTF-8 via TextEncoder; a file uses File.arrayBuffer() (raw bytes, not a data URL).

Jobs this hex does not do

HMAC, password KDFs, SHA-3

HMAC (RFC 2104) is a keyed MAC; it needs a secret the other party already shares. Password storage needs a slow salted KDF — bcrypt, Argon2, or PBKDF2 — not a single unkeyed digest. SHA-3 is FIPS 202, a different sponge construction, and is not offered. The page also does not compare a digest to a published checksum, so it is not a package or ISO verifier. Git historically addressed objects with SHA-1 and later added SHA-256; this site does not implement Git.

Digest hex is not RFC 4648 Base16

abc → ba7816bf… is a checksum; foobar → 666F6F626172 is bytes

Hex on this page is an unkeyed digest, not an encoding. Example: Hash returns ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad because those three ASCII bytes are the FIPS 180-4 SHA-256 example. The Base16 encoder writes RFC 4648 §8 (0–9 A–F, no padding) of UTF-8 bytes. Encoding ASCII foobar writes 666F6F626172. Integer hex ff → 255 on /number-base/ is a radix, not a checksum. #3366cc on /color-converter/ is an 8-bit sRGB triple. The live hash generator does not encode text as hex.

UTF-8 digest is not NFC

SHA-256 of NFC é is 4a99557e…; NFD e + U+0301 produces bf12767b…

The live generator hashes TextEncoder UTF-8 bytes. It does not call String.prototype.normalize. Canonically equivalent é (U+00E9, UTF-8 C3 A9) and é (e + U+0301, UTF-8 65 CC 81) therefore produce different SHA-256 hex.

SHA-256(NFC é) = 4a99557e4033c3539de2eb65472017cad5f9557f7a0625a09f1c3f6e2ba69c4c

SHA-256(NFD e + U+0301) = bf12767b0f2a56b2190075bae8169f656e3ce8d6357d4aff184bc6c7ea48f9f6

Try it with ASCII abc. UAX #15 output e + U+0301 → é (U+00E9) as normalized.txt is /unicode-normalize/. Encoding those same UTF-8 bytes as RFC 4648 §8 hex is /base16/, not a digest.

Hash UTF-8 text or file bytes

Example: Hash returns abc → ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. Unkeyed hex only. Nothing is uploaded.

Use Hash Generator →

FAQ

Which hash algorithm should I use?: Use SHA-256 for new projects. MD5 and SHA-1 are cryptographically broken and should not be used for security.
Is MD5 still safe for checksums?: For non-security checksums (file deduplication), MD5 is fast and fine. Do not use it for passwords or signatures.
What is the result length?: MD5: 128 bits (32 hex chars). SHA-1: 160 bits (40 hex chars). SHA-256: 256 bits (64 hex chars).
Does this tool upload my data?: No. All hashing runs in your browser using Web Crypto or JavaScript. Nothing is sent to a server.

← Back to all articles | Explore all tools →