SHA-1 vs SHA-256: what is the difference
Tools Nimbus is a free, no-signup developer toolkit that runs entirely in your browser, so your data is never uploaded to a server. SHA-256 is the safer choice for anything security-sensitive: its 256-bit digest has no known practical collision, while SHA-1's 160-bit digest was broken by a real collision in 2017 and NIST disallows it after 2030. Use SHA-1 only for non-security legacy checksums. Compare both free in the browser-based Hash Generator.
Last updated July 2026
The short answer
SHA-1 and SHA-256 are both cryptographic hash functions: they take any input and produce a fixed-size fingerprint. The practical difference is that SHA-1 is broken and SHA-256 is not. A hash function's whole job is that you can never find two inputs with the same output, and in 2017 researchers found exactly that for SHA-1. SHA-256, part of the newer SHA-2 family, has no such weakness and is the default you should reach for today. If you only remember one line: use SHA-256 (or SHA-384 / SHA-512) for anything where an attacker might benefit from a forgery, and treat SHA-1 as legacy-only.
Side by side
| Property | SHA-1 | SHA-256 |
|---|---|---|
| Family | SHA-1 (standalone) | SHA-2 |
| Digest size | 160 bits | 256 bits |
| Hex length | 40 characters | 64 characters |
| Collision resistance | Broken (practical collision found) | ~2^128 operations, no known collision |
| First public collision | 2017 (SHAttered) | None |
| Status (as of 2026) | Deprecated; NIST disallows after Dec 31, 2030 | Recommended baseline |
| Relative speed | Slightly faster per byte | Slightly slower, negligible in practice |
| Use for new work? | No (legacy compatibility only) | Yes |
What they have in common
Both are one-way functions: you cannot run them backwards to recover the input from the digest, which is why hashes are used for integrity and fingerprinting rather than for hiding data. Both are deterministic (the same input always yields the same digest) and both show the avalanche effect, where changing a single bit of input flips about half the output bits. Both also produce a fixed-length result no matter how large the input is: SHA-1 always emits 40 hex characters and SHA-256 always emits 64. You can watch all of this directly by typing into the Hash Generator, which computes SHA-1, SHA-256, SHA-384, and SHA-512 side by side using your browser's Web Crypto API.
They share a design lineage too. Both use the Merkle-Damgard construction, processing the message in fixed-size blocks and chaining a running state forward. That shared structure is why both are vulnerable to length-extension attacks, covered further down, and why neither should be used as a bare message authentication code.
Why SHA-1 is considered broken
Security for a hash function is measured by how hard it is to find a collision: two different inputs that produce the same digest. For a 160-bit hash, a generic birthday attack needs about 2^80 operations, which was already within reach of well-funded attackers. In February 2017 a team from Google and CWI Amsterdam went further and published SHAttered, the first practical SHA-1 collision, producing two distinct PDF files with the same SHA-1 digest. Later work drove the cost down and demonstrated chosen-prefix collisions, which are the dangerous kind for forging certificates and signatures. Once a practical collision exists, an attacker can, in the worst case, get you to trust a malicious file that shares a legitimate file's hash. That is why browsers stopped accepting SHA-1 TLS certificates years ago, Git has been moving toward SHA-256 object hashing, and NIST formally retired SHA-1 in 2022 with a full disallow date of December 31, 2030.
SHA-256, by contrast, offers roughly 128-bit collision resistance, and no collision has ever been found. The gap is not incremental: 2^128 is astronomically beyond 2^80, and there is no known shortcut that weakens SHA-256 the way cryptanalysis weakened SHA-1.
Where SHA-1 still shows up safely
Broken for security does not mean useless everywhere. SHA-1 is fine when no attacker can control the input, because collisions have to be deliberately crafted; they do not happen by accident. Detecting accidental corruption in a download, deduplicating cache entries, or acting as a fast non-cryptographic fingerprint are all acceptable, and plenty of legacy systems still emit SHA-1 for these. The rule is simple: the moment an adversary could benefit from two inputs colliding, SHA-1 is the wrong tool. If you are verifying that a published binary was not tampered with, use the SHA-256 checksum the project provides, not its SHA-1 one.
The nuance both share: length-extension
Because both are Merkle-Damgard hashes, if you compute SHA-256(secret + message) and expose the digest, an attacker who does not know the secret can still append data and compute a valid digest for the extended message. This bites people who hand-roll authentication by concatenating a key with data. The fix is not to switch algorithms but to use HMAC (for example HMAC-SHA-256), which wraps the hash in a construction immune to length extension. Choosing SHA-256 over SHA-1 improves collision resistance; it does not by itself make a naive keyed-hash scheme safe.
Neither one is a password hash
A common mistake is storing user passwords as a plain SHA-256. Both SHA-1 and SHA-256 are designed to be fast, which is exactly wrong for passwords: an attacker with a stolen database can try billions of guesses per second, and identical passwords hash to identical values. Password storage needs a deliberately slow, salted algorithm such as bcrypt, scrypt, or Argon2. If you just need a strong secret to begin with, generate one locally with the Password Generator. For the broader picture of when to hash versus encrypt versus encode, see encoding vs encryption vs hashing.
How to choose in one line
Use SHA-256 (or SHA-384 / SHA-512) for anything where integrity matters against a real adversary: checksums you want to prove were not altered, digital signatures, certificate fingerprints, and content addressing. Reserve SHA-1 for legacy interoperability or non-security fingerprints, and never introduce it into new security-sensitive code. To generate and compare either digest in your browser without uploading a thing, open the Hash Generator; to encode binary for transport rather than fingerprint it, use the Base64 Encoder and Decoder. The full set of tutorials lives on the Tools Nimbus guides index.