Why Web Crypto Offers SHA-1 to SHA-512 but Not MD5 or SHA-3

Where is MD5? — the first question from anyone migrating a legacy checksum workflow

The browser's Web Crypto API ships exactly four digest algorithms: SHA-1, SHA-256, SHA-384 and SHA-512. If you reach for the ToolAcre SHA hash calculator expecting MD5 or SHA-3, you will not find them. That specificity is not a limitation of the tool; it reflects a deliberate platform choice. Understanding why these four were included and why two popular alternatives were left out tells you a great deal about how browser APIs are designed.

Every major browser exposes crypto.subtle.digest on secure origins. When your JavaScript calls that method, it passes through to the platform's cryptographic implementation—native code running with security sandboxing and performance optimization. The digest algorithms offered were chosen by the W3C Web Crypto Working Group with specific priorities: compatibility with existing security standards, available support across cryptographic libraries, maturity, and the practical security needs of the web platform.

The four algorithms SubtleCrypto.digest supports — SHA-1, SHA-256, SHA-384 and SHA-512, and nothing else

ToolAcre accepts the same four identifiers enforced by digestBytes: SHA-1, SHA-256, SHA-384 and SHA-512. An unrecognized name is rejected before Web Crypto is called, and the test suite specifically passes MD5 to confirm that rejection. The picker therefore describes a tested product boundary rather than a survey of every digest ever standardized.

SHA-1 appearing in that list does not make all four equivalent recommendations. Its result object carries a broken flag and the interface repeats a legacy warning; the other three are the available SHA-2 choices. Availability and suitability must stay separate whenever a compatibility tool reproduces an old value without encouraging new dependence on it.

MD5 is absent from this implementation and Web Crypto; this article does not add an unsourced standards rationale

MD5 is a cryptographic hash function that produces a 128-bit digest, making it shorter and computationally cheaper than SHA-256. For decades it was the standard choice for checksums and digital signatures. However, MD5's collision resistance is fundamentally broken. In 2004, cryptographers demonstrated practical collisions—two different inputs with the same digest—and the algorithm has been thoroughly dismantled by academic work. The mathematical vulnerability is absolute and permanent.

The W3C Web Crypto specification made a deliberate choice not to include MD5. The reasoning is straightforward: shipping a broken algorithm to millions of browser users would normalize its use in new applications, even though it should only appear in legacy compatibility scenarios. If an application truly requires MD5 for interoperability with old systems, that code belongs in a server-side runtime where the requirement is understood and audited, not in the browser. Making a broken algorithm conveniently accessible would create security expectations in new systems.

The ToolAcre SHA hash calculator does not ship an MD5 implementation either. Like the platform API it uses, it refuses to make a broken algorithm conveniently accessible. If your application absolutely requires MD5—rare outside legacy Git systems—the implementation belongs in your own codebase with a clear note that it is a compatibility shim. Accessibility creates expectations, and broken algorithms deserve no expectations.

SHA-3 is outside the browser API and the tool; its adoption history is outside repository evidence

SHA-3 was standardized by NIST in 2015 after a lengthy public competition, and it is cryptographically solid. It uses a fundamentally different construction from SHA-2, called a sponge, which offers interesting theoretical properties and performance trade-offs depending on your hardware. On modern systems, SHA-3 can be faster than SHA-256. Yet the browser platform does not expose it today, and this delay reflects practical decisions about platform maturity and adoption pace.

The delay in shipping SHA-3 reflects reality: Web Crypto was designed to cover algorithms in broadest use across the web and in HTTPS/TLS. At API finalization, SHA-2 (256, 384, 512) was the overwhelming consensus for new systems, and moving to SHA-3 is happening much more slowly than moving from MD5 or SHA-1. Most applications do not need SHA-3 yet. The cost of expanding the API and testing it across every browser and platform was not justified by demand at launch.

This is not permanent rejection. The Web Crypto API can evolve. If SHA-3 adoption accelerates, the working group could add it. The current set represents the mature, widely-standardized algorithms that Web Crypto needs to serve the platform's immediate security needs. Browser APIs must be stable and carefully maintained; rushing to add features before widespread need creates maintenance burden and compatibility risk for years to come.

Why SHA-1 is still there — legacy verification needs, and the difference between offering and recommending

SHA-1 is included in Web Crypto despite being cryptographically broken. This counterintuitive choice often surprises developers. The algorithm produces a 160-bit digest, and collision attacks against SHA-1 are now practical—two different documents can be crafted to share the same digest. Chosen-prefix collisions allow attackers to craft two documents that are both meaningful while colliding, which breaks signatures and certificates. Yet it remains in the platform.

SHA-1 remains in Web Crypto for one necessary reason: legacy compatibility. Git object identifiers are based on SHA-1, and while the Git project is transitioning to SHA-256, millions of existing repositories, references and build systems still emit SHA-1 hashes. TLS certificate fingerprints from older systems carry SHA-1 digests. APIs that issued HMAC-SHA1 signatures years ago still need validation. These deployed systems must be verified or migrated. The platform includes SHA-1 to make that necessary work possible.

The platform API includes SHA-1 with clear understanding that it is there for compatibility, not recommendation. The browser's UI labels SHA-1 with a warning. The ToolAcre SHA hash calculator displays "Cryptographically broken" next to the SHA-1 result, ensuring that anyone using it understands they are working with legacy material. Transparency is essential; users must never mistake SHA-1 compatibility for SHA-1 endorsement.

If compatibility requires MD5, use a reviewed implementation outside this tool and never mistake compatibility for security

The four algorithms in Web Crypto align with the TLS cipher suite ecosystem and with the most important security standards. SHA-256 is the current default for general-purpose hashing, used in subresource integrity checks, content addressing and new security systems. SHA-512 is faster on 64-bit hardware and offers a wider digest. SHA-384 is primarily known for its use in TLS cipher suites.

SHA-1 is kept for interoperability, not because anyone should start a new system with it. If you are verifying an existing SHA-1 checksum, matching an old certificate fingerprint, or reproducing a Git commit ID, SHA-1 in ToolAcre lets you do that. If you are designing a new system, SHA-256 is the obvious choice. The algorithm you pick signals your understanding of the security model.

What this does not cover — server-side runtimes, which usually expose many more digest algorithms

If your application truly needs MD5, SHA-3 or any other algorithm, the choice is clear: keep that code in the server-side runtime and expose only the final result to the browser. Do not ship your own JavaScript implementation of a cryptographic algorithm for browser use. The browser's native Web Crypto is faster, safer and audited in ways a hand-written JavaScript function cannot match. Delegating to the platform is always the correct choice when the platform provides what you need.

This applies even to "simple" algorithms. A self-written MD5 implementation might seem harmless because MD5 is broken anyway, but broken algorithms have no gradations—they are just broken. Shipping one normalizes the practice of implementing cryptography in application code. The browser provides what the platform needs; use what it provides. Hand-rolled cryptography is the single largest source of security vulnerabilities in web applications because developers underestimate the subtlety and edge cases.

Takeaway: limitations are part of the product — the ToolAcre SHA hash calculator offers the four algorithms the browser implements natively, and documents that boundary

The ToolAcre SHA hash calculator surfaces this constraint directly: you see exactly the four algorithms Web Crypto provides, no more and no fewer. If you paste in a value and think "I need MD5," the absence is intentional. If you need it, that is a signal that your system has a legacy component that needs careful handling—exactly the kind of thing a specialized server-side migration tool is for, not a browser utility. The tool's honesty about what it does and does not offer is itself valuable information.

The Web Crypto design reflects decades of cryptographic practice: algorithms that are standardized, audited, and proven in wide deployment. SHA-256 and SHA-512 are the sensible defaults. SHA-384 carries its TLS lineage. SHA-1 is there because the web has SHA-1 digests that will need to be verified for years. MD5 and SHA-3 are not there because MD5 is broken and SHA-3 is not yet critical to the platform.