Open-sourcing my dev tools as plain HTML files (no npm, no build)
DEV Community

Open-sourcing my dev tools as plain HTML files (no npm, no build)

Open-sourcing my dev tools as plain HTML files (no npm, no build)

Last month I shipped three developer utilities - a Base64 encoder, a Unix timestamp converter, and a CSS minifier. Each one runs 100% in your browser. No servers, no uploads, no analytics, no tracking.

Yesterday I open-sourced them on GitHub. This post is the story of why I built them this way and why I open-sourced them at all.

The problem with "free online tools"

Most "free online tools" secretly upload your input to a server, process it there, and hope nobody keeps a copy. That is a terrible default.

Try this experiment: paste δ½ ε₯½δΈ–η•Œ 🌍 into the most popular online Base64 encoder. About half of them will return Γ₯Β₯½À¸ç‒Œ - broken output that no longer decodes back to what you typed. Why? Because most sites treat text as Latin-1 by accident.

Even when they work correctly, you're trusting that the site:

  • won't log your input
  • won't sell it to a third party
  • won't get breached next year
  • won't disappear and take your workflow with it

Open source fixes all four.

What I shipped

I run aisubtools.xyz - a collection of free online utilities where nothing ever leaves your browser. Yesterday I extracted three of them into a standalone open-source repo:

πŸ”— github.com/enquannacc/aisubtools-browser-tools

Tool What it does
Base64 encoder/decoder Handles UTF-8 correctly via TextEncoder / TextDecoder. No mojibake.
Unix timestamp converter Bidirectional conversion with local and UTC time, plus a live clock.
CSS minifier Regex-based whitespace stripper with before/after size savings.

MIT licensed. No npm install. No build step. No dependencies. Open the file, use it, close the tab. Done.

The architecture: one HTML file per tool

Every tool in the repo is a single self-contained HTML file. Here's the pattern I used across all three:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Base64 Encode / Decode - Browser Tool</title>
  <style>
    /* ~100 lines of CSS - nothing fancy, system fonts, CSS variables */
  </style>
</head>
<body>
  <h1>Base64 Encode / Decode</h1>
  <p>Runs 100% in your browser - nothing is uploaded anywhere.</p>
  <textarea id="input" placeholder="Type or paste here"></textarea>
  <button id="convert">Convert</button>
  <textarea id="output" readonly></textarea>
  <script>
    const input = document.getElementById('input');
    const output = document.getElementById('output');
    const convert = document.getElementById('convert');
    let mode = 'encode';

    function utf8ToBase64(str) {
      return btoa(String.fromCharCode(
        ...new TextEncoder().encode(str)
      ));
    }

    function base64ToUtf8(b64) {
      const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0));
      return new TextDecoder().decode(bytes);
    }

    convert.addEventListener('click', () => {
      try {
        output.value = mode === 'encode'
          ? utf8ToBase64(input.value)
          : base64ToUtf8(input.value.trim());
      } catch (e) {
        output.value = 'Error: ' + e.message;
      }
    });
  </script>
</body>
</html>

Top comments

This is the direction I've drifted toward too - most "free online tools" are just a thin wrapper over a server that keeps your input. Shipping utilities that run entirely in the browser with zero telemetry is genuinely a better default. I built a couple of similar single-file tools (a header-inspector, a small tokenizer) and the "no uploads" property alone makes them usable on other people's machines without them trusting anyone. The Unix timestamp converter + CSS minifier combo is exactly the kind of thing I open a terminal for and then think "why isn't this just a bookmark".

One question - for the CSS minifier, are you doing token-level minification or just whitespace/newline stripping? I've hit edge cases where naive whitespace removal breaks calc(1px + 2px) or media query spacing, so I'm curious how far you went without a build step.

Appreciate the anti-bloat stance. Plain HTML files with no node_modules felt irresponsible to me for years; now it feels like the sane escape hatch.

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.