Hash generator
A hash turns text or a file into a fixed-length fingerprint. This page computes MD5, SHA-1, SHA-256, SHA-384 and SHA-512 locally, HMAC with a key entered as UTF-8, hex or base64, and a verify field that matches an expected digest. Files stay in this tab, capped at 25 MiB. None of these is a password hash.
Choose an input
That text contains an unpaired surrogate; it was replaced with U+FFFD before hashing.
Text is hashed as the bytes you type. This page applies no Unicode normalisation, so é as one code point and é as e plus a combining accent hash differently.
That text contains an unpaired surrogate; it was replaced with U+FFFD before hashing.
Text is hashed as the bytes you type. This page applies no Unicode normalisation, so é as one code point and é as e plus a combining accent hash differently.
The key exists only in this tab. It is never copied into output, a URL, or browser storage.
Digests
Published test vectors
These hash bundled constants. Nothing you type reaches them.
| Vector | Citation | Expected | Computed | Result |
|---|
- Input bytes
- ·
- Algorithm
- ·
- Hex length
- ·
- Requests
- · from Resource Timing
- Script
- · KB of a 100 KB budget
None of these is a password hash
This is the most important sentence on the page, so it is not at the bottom. If you are about to store SHA-256 of a password in a database, stop. These functions are designed to be fast, and fast is precisely the wrong property. A modern GPU rig computes billions of SHA-256 hashes per second, so a stolen table of them is a stolen table of passwords.
What you want is a deliberately slow, salted password hashing scheme: bcrypt, scrypt or Argon2. NIST SP 800-63B-4 section 3.1.1.2 requires that passwords be salted and hashed with one, and that the salt be at least 32 bits. It says the cost factor should be as high as practical without hurting verifier performance, which is a recommendation rather than a requirement. Two things worth being exact about: the approved scheme it points at is PBKDF2, in SP 800-132, so bcrypt, scrypt and Argon2 are our recommendation and not NIST's; and the document does not discuss memory-hardness at all. Your language already has a library for whichever you pick and it is one line. Every hash on this page is the wrong tool for that job, and no option on this page will make it the right one.
HMAC on this page is a shared-secret message authentication code. It is not a signature. It authenticates the message with the key; it does not encrypt the message.
What these are genuinely for: checking that a file arrived intact, deduplicating content, generating a cache key, comparing two payloads without storing either, and verifying a checksum somebody published. Paste the checksum you were given into Expected value (verify) instead of comparing 64 hex characters by eye.
What each one is still fit for
MD5, broken since 2004
Wang and Yu demonstrated practical collisions in 2004, and Stevens, Lenstra and de Weger demonstrated a chosen-prefix collision at Eurocrypt 2007. Their 2009 follow-up made that attack cheap enough to forge a working certificate authority certificate. A chosen-prefix collision means an attacker can construct two different inputs with the same MD5, so "these two files have the same MD5" has not meant "these two files are the same" for two decades. It is still fine for spotting an accidentally truncated download, and it is here because verifying a legacy checksum is a real thing people have to do.
SHA-1, broken for signatures since 2017
The SHAttered attack produced two different PDFs with the same SHA-1 digest. NIST disallowed it for digital signature generation in SP 800-131A. It remains perfectly reasonable as a content address, which is why Git uses it: Git cares about identifying objects, not about resisting an adversary who controls both sides. The HMAC selector keeps the qualifier "legacy only" on SHA-1 for the same reason.
SHA-256, the sensible default
Unbroken, standardized in FIPS 180-4, and what you should reach for unless something names a different one. Its speed is a virtue everywhere except password storage, where it is the flaw.
SHA-384 and SHA-512
SHA-512 works on 64-bit words and is often faster than SHA-256 on a 64-bit machine despite producing twice as much output. SHA-384 is SHA-512 truncated, and it exists mostly because standards and certificate profiles name it. Neither is meaningfully more secure than SHA-256 for any threat that exists today.
Where these come from
The four SHA digests are computed by your browser's own SubtleCrypto implementation of FIPS 180-4, not by a copy of the algorithm shipped in this page. That is both faster and far more likely to be correct.
MD5 is not in SubtleCrypto, deliberately, because the platform does not want to make it easy. It is implemented here in about sixty lines following the reference implementation in RFC 1321, and it was checked against known test vectors including inputs that straddle the internal block boundary, which is where a hand-written implementation goes wrong.
HMAC keys longer than the hash block are hashed first, and shorter keys are zero-padded, which is why RFC 4231 cases 6 and 7 use a 131-byte key. Enter those keys as hex. The self-test panel above runs the published vectors in this tab.
Questions
Can a hash be reversed?
Not by inverting it. But a hash of something predictable can be looked up: every common password's MD5 and SHA-256 have been in public tables for years. That is not reversing the function, it is guessing the input and checking, and it works because these functions are fast. It is the same reason they are unfit for password storage.
Is what I type sent anywhere?
No. The digests appear as you type because computing them takes a fraction of a millisecond in this tab. There is no submit button because there is nothing to submit. A build-time test fails the release if this page makes any request, which is described in how we build tools.
Why do I get a different hash from another tool?
Almost always the input differs rather than the algorithm. A trailing newline is the usual culprit: hashing a file includes the final newline, and pasting its contents into a box often does not. Line endings are the other one, since a Windows file with carriage returns hashes differently from the same text with Unix endings. This page hashes exactly the bytes in the box. It applies no Unicode normalization, so the composed and decomposed forms of the same letter hash differently.
How large a file can it hash?
Up to 25 MiB. Web Crypto and the MD5 compatibility implementation both need the
bytes in memory, so the page sets an explicit ceiling instead of letting a very
large file freeze the tab. For larger files use shasum -a 256 on macOS
and Linux, or Get-FileHash in PowerShell.
Should I use MD5 for anything?
For checking that a file copied correctly, or verifying a checksum from an old vendor page, yes. For anything where somebody might benefit from two inputs matching, no. The distinction is whether an adversary gets to choose the input.
Related tools
To hash a JSON payload reproducibly, sort its keys first with the JSON formatter, or do both steps at the tool chain. For generating a secret rather than fingerprinting one, use the password generator, and for judging one you already have, the password strength checker.