My browser bookmark bar had a folder called "Tools." Inside it:

• A JSON formatter
• A PDF merger (the sketchy one that definitely uploads your file somewhere)
• An invoice generator that watermarks until you pay
• A regex tester
• A color picker
• A CSS gradient generator
• A Base64 encoder
• Three different image compressors because none of them worked perfectly

I used this folder every single week. Sometimes every day. And every time I opened it, I was one mis-click away from losing the folder entirely, or opening a site that had pivoted to freemium since my last visit.

So I did what any reasonable developer does when annoyed enough.

I built the thing I actually wanted.

---

What I actually built

Tooliest is a collection of 102 free browser-based utility tools across 17 categories. The categories cover pretty much every workflow I kept switching tabs for:

• PDF tools — 15 of them
• Developer tools — JSON, Regex, JWT, Diff, Cron, SQL, Chmod
• CSS tools — Gradient generator, Box shadow builder, Flexbox playground
• Color tools — Picker, Palette generator, Contrast checker, Blindness simulator
• Image tools — Compressor, Resizer, Cropper, Format converter
• Finance tools — Invoice generator, Compound interest, Loan analyzer, SIP calculator
• AI tools — Text summarizer, Paraphraser, Email writer
• Text, Encoding, SEO, Social media, Privacy tools

But the tool count isn't actually the point.

---

The constraint that shaped everything

Early on I made a decision that ended up being the hardest technical part of the project: nothing would ever be uploaded to a server.

Every tool would run entirely in the browser. No backend. No file handling on my end. No "your file will be deleted in 24 hours." Your data goes in, gets processed locally, and comes back out — and I never see any of it.

This sounds simple until you try to build a PDF merger in the browser.

For the PDF tools, I ended up using pdf-lib — a pure JavaScript library that handles PDF creation and manipulation entirely client-side. Merging, splitting, compressing, rotating, watermarking, password protecting — all of it happens in a Web Worker so the main thread doesn't block.

For image compression, the browser's Canvas API does the heavy lifting. Feed it a PNG, draw it at reduced quality, export as WebP or JPEG. No upload needed.

The audio converter was the hardest. That one uses ffmpeg.wasm — a WebAssembly port of FFmpeg that runs fully in the browser. The initial load is heavy (~25MB for the WASM binary) but after that, MP3 to WAV to FLAC conversions happen locally with no server involved.

The AI tools are the one exception — they call the Anthropic API, so those requests do leave the browser. Everything else is genuinely local.

---

What I got wrong building this

I prioritized breadth over depth too early

My instinct was to ship as many tools as possible before launch. 100 tools sounds impressive. But from an SEO perspective, 10 deeply-optimized tool pages outperform 100 thin ones. Google cares about page depth, dwell time, and backlinks to individual pages — and I spread myself thin by trying to cover everything at once.

I'm now going back through the highest-potential pages and deepening them: better descriptions, richer FAQ sections, more detailed how-to content on each tool page. Boring work but it's what actually moves rankings.

I underestimated how long AdSense approval takes

The site is monetized through Google AdSense. The approval process took longer than expected and required a minimum content threshold I hadn't fully prepared for. If you're building something similar: apply the moment you have 15+ live, functional pages — not when you feel "ready."

The tool naming is inconsistent

Some tools have very clean URLs (/pdf-merger, /json-formatter) while others are more verbose than they need to be. URL consistency matters for SEO and for users sharing individual tools. Something I'd standardize from day one on the next project.

---

What actually works

The tools that get used most aren't the clever ones. They're the boring, high-frequency ones.

The Word Counter gets hit constantly. The JSON Formatter. The Image Compressor. The Password Generator. Not because they're technically impressive — they're not — but because people need them repeatedly and they bookmark the first one that works without annoying them.

That's the actual product insight: utility tools succeed by removing friction, not by adding features. The reason people return isn't because the tool is better than competitors. It's because the tool didn't make them sign up last time, so they remember it fondly.

---

The stack, if you're curious

No database. No authentication. No backend. The entire site is static files, which means it's fast, free to host, and there's no server to go down.

---

Where it goes from here

The plan is straightforward: go deeper on the tools that already get traffic, add the tools people actually request (a curl builder and HTTP header inspector are next), and let the SEO compound over time.

The passive income math only works if individual tool pages rank. A page ranking for "free pdf merger no upload" sends recurring, intent-driven traffic every single day without any ongoing effort. That's the model. It takes 3–6 months of patience but the unit economics make sense.

---

Try it

👉 tooliest.com

If there's a tool you reach for regularly that I haven't covered — drop it in the comments. I'm still actively building and the best feature ideas have consistently come from people who aren't me.

---

Built this as a side project while studying for an AI/ML certification. If you're building something similar and want to compare notes on the AdSense setup, Netlify config, or the browser-side PDF architecture — I'm happy to talk. Find me in the comments.