Web Crypto hands you four hash algorithms free. MD5 is the one that bills you.

A developer published a build log for a browser-only hash calculator after a file upload failed silently and turned out to have been corrupted in transit with nothing catching it ^[1]. The tool itself is unremarkable, but the decision buried in it is one that every operator verifying files against an older system runs into: the browser's built-in hashing covers four algorithms and pointedly excludes the fifth one the legacy box is asking for ^[3][5].

`crypto.subtle.digest()` handles SHA-1, SHA-256, SHA-384 and SHA-512 natively, with no dependency and no network round trip ^[3]. The author's stated reason for building locally was that no hash tool was installed and uploading sensitive files to an unknown web service felt wrong ^[2], and the finished tool runs entirely client-side ^[11]. MD5 is absent by design, because MD5 is cryptographically broken ^[5]. Defensible as policy, and no help at all when the checksum column in an old database is MD5, or when the counterparty's published checksum is MD5 ^[6].

That leaves two roads: a library such as crypto-js, or an implementation from scratch ^[7]. The author's charge sheet against the library is extra HTTP requests, supply chain risk, bundle size, and fighting module systems ^[8]. The case for hand-rolling is that the algorithm is specified in RFC 1321 and comes to roughly 100 lines of bit manipulation ^[9].

The bill does not arrive in those 100 lines. It arrives at the file boundary. Reading a whole file into memory is fine until a 2GB video crashes the browser, so the tool reads in 1MB chunks ^[10][12]. The author writes that the SHA path is handled by crypto.subtle's incremental interface ^[13]; verify that against your own target, because the only digest call shown in the post is a one-shot over a single buffer ^[4]. For MD5 there was no such option, and streaming state had to be maintained by hand between chunks ^[14].

Which is exactly where it broke. The first version mishandled padding when the final chunk was not a full 512-bit block ^[15]. The corrective prompt was specific: when file size is an exact multiple of 64 bytes the padding needs an extra block, and the appended length is in bits, not bytes ^[16]. Those are the same boundary described twice, since 64 bytes is 512 bits ^[21]. At a 1MB chunk size that is 16,384 blocks per chunk, and the logic only goes wrong on the last one ^[22], which is why the initial MD5 body passed known test vectors while the file path did not ^[18]. Two iterations to fix, and the author's own conclusion is that spotting it required understanding the algorithm first ^[17].

The small parts are the ones worth copying. Input hashing is debounced at 150ms, capping recomputation at about seven passes per second instead of one per keystroke ^[19][23]. Hash comparison is case-insensitive with a MATCH or NO MATCH indicator, on the reasonable assumption that nobody reads 64 hex characters correctly by eye ^[20].

Worth watching: whether your verification target actually requires MD5, because if it will accept SHA-256 the fork disappears and you keep the zero-dependency path. If it will not, test the hand-rolled route at empty input, exactly 64 bytes, and every multiple of 64 near a chunk edge before trusting a green MATCH. This is one developer's account of one tool, with no benchmarks published ^[24].