SHA Hash Generator
Compute SHA-1 / SHA-256 / SHA-384 / SHA-512 in one click
The SHA family compared: SHA-1, SHA-256, SHA-512, and which one to reach for
A tour of the SHA family
SHA is a series of cryptographic hash functions published by NIST. In practice today you will meet the SHA-2 family and, gradually, SHA-3.
| Algorithm | Output | Hex length | Status |
|---|---|---|---|
| SHA-1 | 160 bit | 40 chars | insecure, forbidden for new use |
| SHA-224 | 224 bit | 56 chars | secure, limited use |
| SHA-256 | 256 bit | 64 chars | secure, the general default |
| SHA-384 | 384 bit | 96 chars | secure, common in TLS certificates |
| SHA-512 | 512 bit | 128 chars | secure, when you need longer output |
| SHA3-256 | 256 bit | 64 chars | secure, structurally different from SHA-2 |
SHA-256 is the correct default for almost every situation. Its design, the libraries that implement it, and hardware-acceleration support are all the most mature, and its compatibility is the widest.
Notice that the output size is the only thing most of these share with their security posture; SHA-224 and SHA-256 differ only in truncation, yet both are considered secure, while SHA-1 with 40 characters is not. Security comes from the internal construction and the absence of a known collision, not from how many hex characters the digest happens to print.
Why SHA-1 is unusable
In 2017 the SHAttered project published the first practical SHA-1 collision: two PDFs with different content that share a SHA-1. The compute cost was around $110,000 of GPU time and has only fallen since. Google, Microsoft, and Mozilla jointly deprecated SHA-1 certificates, and mainstream browsers refuse to connect to a SHA-1-signed certificate.
Like MD5, SHA-1's problem is that its collision resistance is broken, not that it "can't compute enough bits." It still computes — it just can no longer prove that "two contents differ."
For that reason, any system still emitting SHA-1 signatures is on borrowed time; the deprecation is not a warning about a future risk but a response to a risk that already exists. If you maintain such a system, the migration path is to SHA-256, and the earlier the better.
Where SHA-256 shows up
- TLS certificate signatures. Every HTTPS site you visit carries a chain of SHA-256 behind it.
- Git object identifiers. Each commit, tree, and blob hash is SHA-1 (newer versions can migrate to SHA-256) — the basis of content addressing.
- Software-package integrity. npm, Maven, and Docker image layers all use it for checksums. A Docker image ID is itself a SHA-256 prefix.
- Subresource Integrity (SRI). A page's
<script integrity="sha384-...">lets the browser verify the hash before loading an external script and refuse to run it if tampered. - Blockchains. Bitcoin's proof of work computes SHA-256 repeatedly — and twice over.
What unites these cases is that SHA-256 is used as a content fingerprint that honest parties compare, not as a secret. Nobody is trying to find two different Git blobs that hash alike, so SHA-256's collision resistance is never actually exercised in anger there — it is the ubiquity and the tooling, not the threat model, that make it the default.
What a hash cannot replace
Do not use a bare hash for integrity authentication. If an attacker can change both the content and the hash (say, alter a file and the checksum printed on the page), verification means nothing. To stop tampering you need a keyed HMAC, a digital signature, or a hash stored somewhere the attacker cannot reach (an HTTPS site, a signed release channel).
Do not use a hash to store passwords. SHA-256 is fast, and fast is the weakness here — GPUs compute billions per second. Password hashing needs to be slow, using bcrypt, scrypt, or Argon2 with tunable cost and a per-account random salt.
Hashing is irreversible. That is a feature, not a defect, but it also means hashing cannot protect data you later need to recover. Encryption is reversible; hashing is not.
People reach for a hash in these places because hashing is the obvious first tool, and it is genuinely the right primitive — just the wrong mode. The fix is almost always to add a key (HMAC), a keypair (signature), or a trusted location, not to swap SHA-256 for a "stronger" hash. A longer digest does nothing against an attacker who controls both the value and its checksum.
How to use this tool
Paste text to get SHA-1, SHA-256, SHA-384, or SHA-512. Computation uses the browser's built-in Web Crypto API, runs entirely locally, and sends no input to any server. For very large files (gigabytes), the browser API must read everything into memory at once, so a streaming command-line tool such as sha256sum is the better fit.
When verifying a downloaded file, compare character by character: if the length is wrong it is not the same hash, and you need not read the contents at all. The tool toggles case, because some publishers distribute their checksums in uppercase.
FAQ
Should I use SHA-256 or MD5?
Use SHA-256 for integrity checks. Both MD5 and SHA-1 are vulnerable to collision attacks and are not safe for security-sensitive use.
Why does it say the environment is unsupported?
The WebCrypto digest API is only available over HTTPS or on localhost. Once deployed online it works fine.