Hash Generator

What this does

Paste text or drop a file and you get all four SHA digests at once — SHA-1, SHA-256, SHA-384 and SHA-512 — as lowercase hex. There is no algorithm picker because computing all four costs nothing; copy the row you need. Hashing runs through the browser's crypto.subtle.digest, so text and files are read locally and never uploaded.

Which SHA algorithm should I use?

SHA-256 unless something tells you otherwise. The differences are digest length and whether the algorithm is still collision resistant:

SHA-384 is not a separate design — it is SHA-512 with different initial values, truncated to 384 bits.

How do I check a downloaded file against a published checksum?

1. Switch to the File tab and drop the download on the box.
2. Find the row for the algorithm the publisher used — usually SHA-256.
3. Compare the whole string against their SHASUMS256.txt or release notes, not just the first few characters. Any difference means the file is not the one that was published — re-download it.

A match proves the bytes are intact. It does not prove the publisher is trustworthy, and it proves nothing if the checksum came from the same page that served a tampered file.

Why is the output hex instead of base64?

Hex is what shasum, sha256sum and virtually every published checksum uses, so it is what this tool emits. A few places want the digest base64-encoded instead — subresource integrity attributes such as integrity="sha384-…", and some S3 and webhook signature headers. Those encode the raw digest bytes, not the hex text, so base64-encoding the string on this page will not get you there. Use the command line:

# hex, same as the SHA-384 row on this page
$ shasum -a 384 app.js

# raw digest bytes, base64 — the form SRI wants
$ openssl dgst -sha384 -binary app.js | openssl base64 -A

Is SHA-1 still safe to use?

Not for anything security-relevant. Practical collisions have existed since 2017: two different files can be produced with the same SHA-1 digest. It survives where a hash is an identifier rather than a guarantee — git commit and blob IDs — and in older APIs you do not control. Use it for compatibility, never as proof that content was not swapped.

Can I hash a password with this?

No. A raw SHA digest is built to be fast, which is exactly wrong for passwords — a GPU grinds billions of guesses per second. Store passwords with a deliberately slow, salted algorithm: argon2id, scrypt or bcrypt. This is also not an HMAC tool; HMAC mixes a secret key into the digest, and this page only hashes what you give it. To generate a strong secret, use the password generator. Web Crypto omits MD5 entirely, so legacy checksums go through the MD5 tool.

What does a digest actually look like?

Deterministic and fixed-length whatever the input size. The three-byte string abc gives:

SHA-1    a9993e364706816aba3e25717850c26c9cd0d89d
SHA-256  ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Change one character and every hex digit changes. Text is UTF-8 encoded before hashing, so café hashes as its five UTF-8 bytes — matching your server only if it reads the input as UTF-8 too. Related: Base64 and the JWT decoder.