Hash Generator
SHA-1, SHA-256, SHA-384 and SHA-512 of any text, all four at once, in hex or Base64. No MD5 — Web Crypto does not implement it.
Encoded as UTF-8 before hashing. A trailing newline or a BOM changes every digest.
13 characters · 13 UTF-8 bytes
digest = SHA-x(UTF-8 bytes) · fixed length whatever the input size · 160 / 256 / 384 / 512 bits
A digest is one-way but not secret: an unsalted hash of a password, an email address or a phone number is recovered by lookup. Use Argon2id, scrypt or bcrypt for passwords, and HMAC when a key is involved. Text only — this does not hash files, and MD5 is deliberately absent.
How it works
Type or paste text. It is encoded as UTF-8 first, because hashing runs on bytes and not on characters — the same words in UTF-16 or Latin-1 produce a completely different digest. The character count and the UTF-8 byte count are shown under the field so the two are never confused.
All four digests are computed in the page by the browser’s Web Crypto API — crypto.subtle.digest, the same primitive TLS and Subresource Integrity use. There is no request to inspect, because there is no request.
Pick the output form. Lowercase hex is what shasum, sha256sum and most CLIs print; uppercase hex is what Windows certutil and PowerShell Get-FileHash print; Base64 is what a Subresource Integrity attribute and most HTTP digest headers carry. They are three spellings of the same bytes.
Check the digest length before assuming a value is wrong. SHA-1 is 160 bits (20 bytes, 40 hex characters), SHA-256 is 256 (32 bytes, 64), SHA-384 is 384 (48 bytes, 96) and SHA-512 is 512 (64 bytes, 128). Length is the fastest way to confirm you are reading the algorithm you meant.
Copy the one you need, or copy all four as a labelled block.
What a digest is, and why the four lengths differ
SHA-1 and the SHA-2 family (SHA-256, SHA-384, SHA-512) are specified in FIPS 180-4. Each pads the message to a multiple of the block size — 512 bits for SHA-1 and SHA-256, 1024 bits for SHA-384 and SHA-512 — appends the original bit length, then runs a compression function over every block in turn, carrying a fixed-size internal state forward. The state at the end is the digest, so a one-byte input and a one-gigabyte input produce the same number of output bits. Changing a single bit of the input flips roughly half the output bits, which is why two digests either match exactly or tell you nothing about how close the inputs were. SHA-384 is not a shortened SHA-512 in the loose sense: it is SHA-512 run with different initial hash values and then truncated to 384 bits, and that truncation is what makes it resistant to the length-extension attack the other three are open to.
SHA-256("abc") = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad (FIPS 180-4 test vector)
Use cases
Checking a published SHA-256 against a download
A project that publishes a checksum expects you to hash the FILE, not text pasted out of it. Use shasum -a 256 file on macOS and Linux, certutil -hashfile file SHA256 on Windows, or Get-FileHash file -Algorithm SHA256 in PowerShell. This page is for the text case and for reading the format: it will not reproduce a file digest unless the bytes are byte-identical, and a trailing newline or CRLF line endings are enough to make them not be.
Subresource Integrity attributes
integrity="sha384-oqVuAfXRK..." is the Base64 of the raw digest bytes, not Base64 of the hex string, and SRI accepts sha256, sha384 and sha512 only — never sha1. SHA-384 is the common choice. That is what the Base64 toggle here is for. For a real script file the command is openssl dgst -sha384 -binary app.js | openssl base64 -A; the digest must be recomputed on every build, because a one-character change invalidates it and the browser will then refuse to run the file.
Git object ids
A Git blob id is SHA-1 over the string "blob ", the content length in bytes, a NUL byte, and then the content — not over the content alone. That header is why hashing a file’s text here does not reproduce its object id; git hash-object does. Git can be initialised with SHA-256 object ids (git init --object-format=sha256), but the format is still uncommon and most hosts do not accept it.
Webhook signatures are HMAC, not a plain hash
Stripe, GitHub and Slack sign webhook bodies with HMAC-SHA256 — a keyed construction over the payload and a shared secret, defined in RFC 2104. A bare SHA-256 of the request body will never match one of those headers, and nothing here takes a key. Verify server-side with your platform’s HMAC function and a constant-time comparison, because comparing digests with == leaks their contents through timing.
The same digest in hex and in Base64
Converting between them is re-encoding, not re-hashing. SHA-1 is 20 bytes: 40 hex characters or 28 Base64. SHA-256 is 32 bytes: 64 hex or 44 Base64. SHA-384 is 48 bytes: 96 hex or 64 Base64 with no padding. SHA-512 is 64 bytes: 128 hex or 88 Base64. If a value has the right length for one spelling and you are comparing it against the other, that alone explains the mismatch.
Uppercase, lowercase and stray spaces
sha256sum and shasum print lowercase hex. Windows certutil prints uppercase in space-separated pairs. PowerShell Get-FileHash prints uppercase unspaced. Hex is case-insensitive as a value but string equality is not, so a comparison in code has to normalise case and strip whitespace first — the uppercase toggle here exists so a value can be matched against a vendor document without doing that by eye.
Cache keys, ETags and content-addressed storage
Naming a stored object by the digest of its contents makes a URL immutable and deduplication free — the uploads on this site are named by their SHA-256 for exactly that reason. SHA-1 is still adequate where the content is yours and an accidental collision is the only risk, since the odds of one are effectively zero. It is not adequate the moment a stranger chooses the content, because then the collision is chosen rather than accidental.
Why none of these belongs near a password
SHA-2 is designed to be fast, and a consumer GPU tries billions of SHA-256 candidates a second. Password storage needs a deliberately slow, memory-hard KDF with a per-user salt: Argon2id, scrypt or bcrypt. The same reasoning kills "hash the email address to anonymise it" — an email, a phone number and a national id all come from a space small enough to enumerate, so the digest identifies the person exactly as well as the value did.
SHA-256 or SHA-512, and where SHA-384 fits
Both are unbroken; picking between them is a performance and interoperability question, not a security one. SHA-512 works on 64-bit words and is usually faster per byte on a 64-bit CPU with no crypto instructions, but x86 SHA-NI and the ARMv8 crypto extensions accelerate SHA-256 and not SHA-512, which reverses that on most current hardware. Reach for SHA-384 when you want a truncated digest that resists length extension without wrapping the hash in an HMAC.
Questions
- Why is there no MD5?
- Because Web Crypto does not implement it, and that omission is deliberate on the standard’s part rather than an oversight. MD5 collisions have been practical since 2004 and take seconds on a laptop today; a chosen-prefix collision was used in 2012 to forge a Microsoft code-signing certificate. MD5 is still legitimate as a NON-security checksum — spotting accidental corruption in a transfer, a cache key over your own data, matching an S3 ETag — and md5sum, certutil -hashfile file MD5 or Get-FileHash -Algorithm MD5 do that locally. For anything where someone might want two inputs to collide, use SHA-256. Shipping a hand-written MD5 on this page would put a broken primitive on a page people open to be careful.
- Is SHA-1 safe to use?
- Not for anything an attacker can influence. NIST disallowed SHA-1 for digital signature generation after 2013; the SHAttered research produced a real collision in 2017; and the 2020 chosen-prefix attack, "SHA-1 is a Shambles", cost roughly 45,000 US dollars of rented GPU time and is cheaper now. It is included here because Git object ids, older certificate chains and plenty of legacy APIs still print SHA-1 and you need to be able to read them, not because it should be chosen for new work.
- Is my text sent anywhere?
- No. crypto.subtle.digest runs in the page, so there is no upload, no logging and nothing kept between visits. The text also never leaves the tab: this page stores nothing in localStorage or cookies, and the whole /tools section carries no analytics or advertising script.
- Can a hash be reversed?
- Not by inverting the function. It can be reversed by lookup, which is the failure people actually hit: a digest is deterministic and unsalted, so a common password, an email address or a phone number is recovered by hashing candidates until one matches, and precomputed tables for the obvious inputs already exist. A hash hides an input only when that input is unpredictable.
- Why does my digest not match the server’s?
- Almost always the bytes differ rather than the algorithm. The usual causes are a trailing newline (echo adds one — use printf or echo -n), CRLF instead of LF line endings, a UTF-8 BOM at the start of the file, or leading and trailing whitespace from a copy-paste. After that, check you are comparing the same representation and the same case: hex and Base64 of one digest look nothing alike.
- Can it hash a file?
- No. This tool takes text only. For a file, shasum -a 256 file, certutil -hashfile file SHA256 or Get-FileHash are the right tools, and they read the bytes off disk rather than through a text field that would normalise line endings on the way in.
- Can it do HMAC, or a salted hash?
- No. HMAC takes a key, and a page that asks you to paste a signing secret into a text field is a bad habit to build even when the page is honest about running locally. Use your language’s HMAC function server-side. Salting is the same answer from the other direction: a salt has to be generated per record and stored with it, which is a database concern rather than a calculator one.
More tools
One of 18 free tools here. They come out of building utility apps for macOS, iOS and the browser — all of it by one person.
See the apps