SHA-1 vs SHA-256

August 18, 2026 · 13 min read

SHA-1 and SHA-256 are both members of the SHA family, but they offer different security margins. SHA-1 produces a 160-bit digest; SHA-256 produces 256 bits. For any new security-sensitive use in 2026, choose SHA-256 or stronger - SHA-1 is legacy.

You will still see SHA-1 in old Git repos, legacy APIs, and aging certificates. Knowing why it was deprecated helps you plan migrations without breaking integrators overnight.

Basics side by side

           SHA-1          SHA-256
Digest:    160 bits       256 bits
Hex len:   40 chars       64 chars
Status:    Deprecated     Recommended

Both are fast and unkeyed. Performance differences rarely matter compared to network I/O. Pick SHA-256 for fingerprints, integrity tags, and certificate signatures unless an external standard forces otherwise.

Collision attacks

A collision is two different inputs with the same hash. Researchers demonstrated practical SHA-1 collisions (SHAttered, 2017). Attackers could forge documents that share a SHA-1 digest with a benign file - breaking trust in signatures that relied only on SHA-1.

SHA-256 has no known practical collision attacks. NIST and browsers phased out SHA-1 for TLS certificates; Git added collision detection for object IDs. Treat SHA-1 like MD5 for security decisions: legacy compatibility only.

Industry deprecation

Major browsers stopped trusting SHA-1 TLS chains. Package registries and CDNs prefer SHA-256 for checksums. Compliance frameworks (PCI, SOC audits) flag SHA-1 in cryptographic controls. Document your hash algorithm in API specs so clients do not silently depend on weak digests.

TLS and code signing - SHA-256 or SHA-384 minimum.
Content integrity (SRI, npm integrity) - SHA-256.
Password storage - neither; use bcrypt or Argon2.

Migrating safely

Support dual verification during transition: accept SHA-256 signatures while still reading legacy SHA-1 for a bounded period. Re-hash static assets and publish new digests. For APIs, version endpoints (/v2/signatures/sha256) instead of changing behavior silently.

const algo = "sha256"; // never "sha1" for new code
const digest = createHash(algo).update(body).digest("hex");

When SHA-1 still appears

Old Git objects use SHA-1 for commit IDs; Git added SHA-256 object format optionally. Legacy HMAC-SHA1 integrations may linger in enterprise webhooks - migrate partners with clear deadlines. Non-security uses (partition keys, quick and dirty caches) sometimes still use SHA-1; even there SHA-256 is cheap insurance.

When auditing dependencies, grep for sha1 in crypto configs and CI checksum files - upgrade paths are usually mechanical.

FAQ

Is SHA-1 broken for everything?: Collision attacks break collision resistance, not all uses. Still, treat SHA-1 as unsafe for signatures and integrity.
Is SHA-256 slower than SHA-1?: Slightly, but negligible for typical payloads. Hardware acceleration makes both fast.
What about SHA-512?: SHA-512 is stronger and part of SHA-2. SHA-256 is the default sweet spot for interoperability.
Do Git commit hashes need migration?: Only if you adopt Git’s SHA-256 object mode. Most repos remain SHA-1 commit IDs for history compatibility.

Related: SHA-256 explained simply

Browse all tools