I built 70+ free browser tools in plain HTML/CSS/JS — here's what I learned

I built 70+ free browser tools in plain HTML, CSS and JS — here's what I learned

A few months ago I got frustrated with every free online tool site on the internet.

You search for something simple — a JSON formatter, a word counter, an image compressor — and you land on a page that takes four seconds to load, throws three popups at you, asks you to sign up to do anything useful, and buries the actual tool somewhere below the fold under a wall of ads.

So I built the alternative.

Tools2Do is now 70+ free browser-based utilities. No login. No popups. No server uploads. Everything runs locally in your browser.

This post is about what I learned building it — the technical mistakes, the SEO discoveries, and the stuff nobody tells you about shipping a multi-tool platform solo.

The tech stack (deliberately boring)

No React. No Vue. No build step. No npm. Just:

• Plain HTML
• CSS custom properties
• Vanilla JavaScript

Every tool is a static index.html file. The whole site deploys on Vercel in under 30 seconds.

This was a deliberate choice. The tools need to be fast. Not "fast for a React app" fast — actually fast. Sub-second load times on mobile. No framework overhead. No hydration. No bundle splitting needed because there's no bundle.

The tradeoff is that you write more boilerplate HTML across files. Worth it.

The biggest technical mistake I made

I wrote inline onclick handlers for almost every tool button, using bare element ID references like this:

<textarea id="input"></textarea>
<textarea id="out" readonly></textarea>
<button onclick="out.value = JSON.stringify(JSON.parse(input.value), null, 2)">
  Format JSON
</button>

This pattern — treating element IDs as implicit global variables — actually works in most browsers most of the time. Older spec behavior made id attributes available on window automatically.

But it fails silently in certain contexts:

• When another variable or function in scope shadows the ID name
• In strict mode contexts
• When the element hasn't rendered yet
• On some mobile browsers with aggressive memory management

I had 11 tools silently broken because of this. Users clicking buttons and nothing happening. No error in the console. Just nothing.

The fix: Always use document.getElementById() explicitly, and always wrap initialization in DOMContentLoaded:

document.addEventListener('DOMContentLoaded', function() {
  var input = document.getElementById('input');
  var out = document.getElementById('out');

  document.getElementById('format-btn').addEventListener('click', function() {
    try {
      out.value = JSON.stringify(JSON.parse(input.value), null, 2);
    } catch(e) {
      out.value = 'Invalid JSON: ' + e.message;
    }
  });
});

Explicit. Predictable. Works everywhere.

What I learned about browser APIs for tool building

Building 70+ tools means you end up using a lot of Web APIs you'd otherwise never touch. A few worth knowing:

crypto.randomUUID()

For the UUID generator, I originally wrote a manual implementation using Math.random(). Don't do this — the randomness isn't cryptographically strong and UUIDs generated this way have collision risk at scale.

The browser has a native API:

function generateUUID() {
  if (crypto.randomUUID) return crypto.randomUUID();
  // Fallback for older browsers
  return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
    var r = crypto.getRandomValues(new Uint8Array(1))[0] % 16;
    var v = c === 'x' ? r : (r & 0x3 | 0x8);
    return v.toString(16);
  });
}

Always provide a fallback. crypto.randomUUID() is widely supported but not universal.

Clipboard API

Every tool needs a copy button. The modern way:

async function copyToClipboard(text) {
  try {
    await navigator.clipboard.writeText(text);
    showFeedback('Copied!');
  } catch(e) {
    // Fallback for HTTP or permission denied
    var el = document.createElement('textarea');
    el.value = text;
    document.body.appendChild(el);
    el.select();
    document.execCommand('copy');
    document.body.removeChild(el);
    showFeedback('Copied!');
  }
}

The fallback matters. navigator.clipboard is blocked on HTTP (non-HTTPS) and in some iframe contexts. Without the fallback your copy button silently fails for a portion of users.

File API for image tools

For image compression and resizing, everything runs client-side using Canvas:

function compressImage(file, maxSizeKB, callback) {
  var reader = new FileReader();
  reader.onload = function(e) {
    var img = new Image();
    img.onload = function() {
      var canvas = document.createElement('canvas');
      canvas.width = img.width;
      canvas.height = img.height;
      var ctx = canvas.getContext('2d');
      ctx.drawImage(img, 0, 0);

      var quality = 0.9;
      var result;
      do {
        result = canvas.toDataURL('image/jpeg', quality);
        quality -= 0.05;
      } while (result.length / 1024 > maxSizeKB && quality > 0.1);

      callback(result);
    };
    img.src = e.target.result;
  };
  reader.readAsDataURL(file);
}

The user's image never leaves their device. This is both a privacy feature and a scaling feature — you have zero server costs for image processing.

The SEO things that actually matter for a tool site

I spent a lot of time on SEO for this project and learned more than I expected.

Thin content is your biggest enemy

Most tool sites have pages that look like this:

• Tool widget
• 200-word generic description
• Four FAQ bullets

Google sees this as thin content and won't rank it. The fix isn't just writing more words — it's covering the topic properly. For a JSON formatter page, that means explaining what JSON is, what formatting does, common errors, use cases, and related tools. Aim for 600-900 words of genuinely useful content per tool page.

Schema markup actually works

Implementing WebApplication schema with proper offers, operatingSystem and applicationCategory fields gives Google richer signals about what your page is. FAQ schema on tool pages gets your FAQs into the SERPs directly.

What doesn't work: HowTo schema was deprecated by Google in September 2023. I had it on 71 pages. Removed all of them.

The E-E-A-T problem nobody warns you about

Google's quality guidelines treat tool sites as potentially low-trust by default. Anonymous authorship, no editorial policy, generic contact details — all of these are flags.

The fixes that moved the needle for me:

• Written editorial policy (not one sentence — a real one)
• Named author attribution on all blog content
• Domain email instead of Gmail
• External sameAs links in Organization schema (LinkedIn, GitHub)

None of this is technically difficult. It's just work most tool sites skip.

Boilerplate injection kills you

I made the mistake of appending the same "About [Tool Name]" block to every page automatically — including the About page, Contact page, and Blog index. This creates near-duplicate content across 80+ pages and signals automated content generation to Google's quality systems.

If you're building a tool platform, make sure your About page, Contact page, and blog index have completely unique content. The boilerplate belongs only on tool pages, and even there it should be minimal.

The niche that surprised me

I built Tools2Do expecting the developer tools (JSON formatter, Base64 encoder, regex tester) to get the most traffic.

The actual top performers are the Pakistan utility guides — step-by-step guides for BISP 8171 status checks, electricity cross-subsidy applications, and the Punjab petrol relief scheme.

These pages get more organic traffic than any developer tool on the site. The reason is simple: there's genuine demand, the official government processes are confusing, and almost nobody has written clear guides for them.

If you're building a tool site, look for underserved niches where you can be genuinely useful — not just another alternative to an established tool.

What I'd do differently

Write the JS properly from day one. The bare ID reference pattern cost me debugging time across dozens of files. getElementById everywhere, always, from the start.

Plan your URL structure before building. I ended up with some inconsistencies between tool categories that are now locked in because changing them breaks links.

Start the SEO work earlier. Schema markup, meta descriptions, and editorial credibility signals take time to build trust. Starting on day one instead of month three would have compounded faster.

Build fewer tools better. 70+ tools sounds impressive but 20 excellent tools with rich content, real JS quality, and strong schema would probably outperform it.

The site

If you want to see the result: tools2do.com

Everything is free, runs in your browser, and doesn't require a login. If something's broken or missing a feature you'd use, let me know in the comments — I'm genuinely taking notes.

Tags: webdev javascript html showdev