Creating 300+ Free Browser Tools: My Journey

There are 301 tools on this site at the time of writing, across 18 categories — 65 design tools, 36 for developers, 27 mathematical, and a long tail of things like a timezone meeting planner and an HTML entity encoder. The whole directory is 4.7MB.

That number is less impressive than it sounds, and the reason why is the actual lesson. Nothing here took a week. What made 300 possible was settling the architecture early enough that each new tool became a small, bounded piece of work instead of a project.

It started with not wanting to open a tab

The first one was a CSV to JSON converter, written because I was converting CSV to JSON several times a week and the sites I was using were covered in adverts, had a file size limit, and — the part that actually bothered me — wanted me to upload the file to find out.

That last point turned into the founding constraint: the data never leaves the browser. Everything runs client-side. Not as a privacy feature to advertise, but because it removed an entire category of problem. No uploads means no storage, no retention policy, no abuse handling, no per-user cost. A tool that runs entirely in your tab costs me nothing whether it is used once a year or ten thousand times a day.

Almost every subsequent decision fell out of that one.

The shape that made 300 possible

Each tool is a folder containing exactly two things: a JSON file describing it, and an index.php that renders it.

tools/
  csv-to-json-converter/
    tool.json
    index.php
  hash-generator/
    tool.json
    index.php

The JSON carries the metadata:

{
  "name": "Hash Generator",
  "slug": "hash-generator",
  "description": "Generate MD5, SHA-1, SHA-256 and SHA-512 hashes from text.",
  "category": "Developer",
  "version": "1.0.0"
}

A registry service scans the directory and syncs what it finds into an index, so the listing pages, the category filters, the search and the sitemap all come from the folder itself. Adding a tool means creating a folder. There is no registration step to forget, no central file to edit, and therefore no chance of the list and reality drifting apart.

This is the part I would tell anyone attempting something similar. The cost of the hundredth item is set almost entirely by how much ceremony surrounds adding one. Get that near zero and volume stops being the hard part.

Rules I settled on

No build step. Every tool is plain HTML, CSS and JavaScript, served as written. There is no bundler, no framework, no node_modules. A tool written three years ago still runs, because there is no toolchain underneath it to rot. Two of the 301 load an external script, both for a genuinely non-trivial parser, and I have been meaning to remove them.

Works without an account. No sign-up, no email, no free tier. Every tool is fully usable the instant it loads.

One tool, one job. A "developer toolkit" with twelve tabs is harder to find and harder to link to than twelve separate pages. Splitting them also means each page can answer one specific question a person actually typed into a search box.

No adverts. This is the one I am least sure survives at scale, but it is the reason I built the first one, and it would be strange to reproduce the thing I was annoyed by.

What I got wrong

I over-designed the first few. The initial tools had settings panels, theme toggles and options nobody used. The ones that get used are the ones that do the obvious thing immediately, with the controls that matter visible and nothing else. Later tools are considerably plainer and considerably more popular.

I did not think about naming. Early tools got clever names. Nobody searches for a clever name. They search for "convert csv to json", so the tool is called a CSV to JSON converter, and that is the whole of my naming strategy now.

I treated categories as fixed. I started with a handful and now there are 18, several of which exist because a tool did not fit anywhere. Design ended up with 65 tools, which is really three categories that have not been split yet. Getting taxonomy right up front is not possible; leaving room to change it is.

I skipped the metadata. For a long time tools had a name and nothing else, which meant every one of them had an almost identical page title and no description. That is invisible while you are building and very visible when you look at how they perform in search. Adding a real description to each was tedious and worth it.

On making them free

The honest answer is that charging would cost more than it earns. A payment system means accounts, which means passwords, billing, support, refunds and a privacy policy that has to mean something — for tools that each solve about thirty seconds of somebody's problem.

Free also happens to be the only model consistent with the client-side constraint. If nothing leaves your browser, there is nothing to meter.

There is a quieter benefit. Because no tool needs to justify itself commercially, obscure ones are allowed to exist. A byte converter or an HTML entity encoder will never be popular, and they do not need to be. They cost a folder.

What I would do differently

Start with the registry. I hand-maintained a list for the first thirty or so tools, and it was wrong within a week of me forgetting about it. The scan was the change that made the rest possible, and I made it far too late.

And write the description as you write the tool, not in a batch six months later. You know what a tool does on the day you build it more precisely than you will ever know again.