Zero npm installs: I built a 40-page developer toolbox that loads in milliseconds

I needed to decode a JWT last week. I searched, clicked the first result, and got a login wall. The second site wanted me to "create a free account" to see my own token's payload. The third one was a 4MB React bundle that showed a spinner for three seconds before rendering a text box. So I did what developers do when annoyed enough: I built my own. DevUtils is now 40 pages, 19 tools, one shared stylesheet, and zero npm dependencies. This post is about the technical decisions that made that possible — and the ones that made it worth doing. The constraint that shaped everything One rule, no exceptions: every tool runs 100% in the browser. No backend, no API calls, no analytics (yet), no CDN scripts. Your data never leaves your device — and this isn't a privacy promise on a marketing page, it's verifiable: open the network tab while using any tool and watch the silence. This constraint sounds restrictive. It was actually liberating, because it eliminated entire categories of complexity: No build step. The files I edit are the files I deploy. No framework churn. No React 18 → 19 migration in my future. No supply chain. Nothing to audit, nothing to update for security patches. The multi-page bet Most tool sites are single-page apps with client-side routing. I went the other way: one HTML file per tool. Every tool gets its own URL, which is exactly what SEO wants Each page is independently cacheable and loads in milliseconds If I break the regex tester, the JSON formatter doesn't care Deep-linking and bookmarking work the way the web intended The whole site — 40 pages — is about 120KB zipped. That's smaller than most sites' JavaScript alone. When zero dependencies means writing it yourself Here's where it gets fun. Three tools don't exist in the standard browser API, and I refused to pull in a library for each: 1. The MD5 hash generator. Web Crypto gives you SHA-1 through SHA-512, but MD5 is deliberately excluded. My hash generator needed it (non-adversarial checksums are still everywhere), so I implemented RFC 1321 from scratch — about 70 lines of bit-twiddling with the four-round mixing functions. Then I tested it against reference vectors: empty string, abc, "message digest", Chinese text, 200-character inputs spanning block boundaries. Seven for seven against Node's crypto. 2. The Markdown parser. My Markdown previewer needed MD→HTML conversion. Instead of loading marked or markdown-it (excellent libraries, and also two more things to load), I wrote a ~100-line parser covering the practical subset: headings, emphasis, inline code, fenced blocks, links, lists, blockquotes, tables, rules. The trick that makes it safe: escape all HTML first, then apply Markdown structure — so nothing the user types can execute as markup. 3. The CSV parser. "Just split on commas" is how CSV parsers break. RFC 4180 quoting means fields can contain commas, newlines, and escaped quotes. My CSV to JSON converter implements the real state machine, so Excel exports with multi-line cells convert correctly. Was this the fastest path? No. Was it the most educational and the lightest to ship? Yes. And each hand-written piece is small enough to actually understand — the whole MD5 implementation is shorter than most dependency lists. The tools people actually use The full set covers the daily-carried utilities: JSON formatter & validator with precise error line/column Regex tester with live highlighting and capture groups JWT decoder that humanizes exp claims into "VALID — expires in 47m" Base64 that handles UTF-8 correctly (paste 你好 or emoji, no mojibake) Unix timestamp converter with a live epoch clock UUID generator, color converter, password generator, text diff, slug generator, word counter, case converter, and more Plus reference pages like a regex cheat sheet, because sometimes you don't need a tool — you need to remember what (?