我打造了 75 款免費工具，拒絕上傳你的檔案

Here is a small ritual you probably know.

You need to compress one PDF. Or shrink one photo. You search, you click the first result, you drag your file onto a stranger's server, you make an account you will never use again, you wait – and then the download button asks for money.

I got tired of performing that ritual with documents that had no business being on someone else's server in the first place. A signed agreement. A scan of an ID. Family photos. So I built the version I wanted to exist: ToolPixi – 75 free tools that run entirely in your browser. Your files never leave your device, because technically, they can't. There is no upload endpoint to send them to.

This post is about why I built it that way, what I put in it, and what building 70 tiny tools taught me that building one big one wouldn't have.

The privacy thing is an architecture decision, not a promise

Every hosted file tool asks you to trust a privacy policy. Policies are words. Architecture is physics.

When a tool runs client-side – the browser reads the file with the File API, processes it in JavaScript, and hands you back a download generated on your own machine – there is nothing to trust. No request carries your file anywhere. You can open the network tab and watch: the only thing that loads is the page itself.

That constraint shaped everything. Some operations are easy in a browser (merging and splitting PDFs, re-encoding images on a canvas, conversions between everyday formats). Some are genuinely awkward – the browser gives you no filesystem, memory is not infinite, and a huge file will humble a phone quickly. But the awkwardness is the point. The moment you add a server "just for the big files," you have rebuilt the exact thing you are trying to replace.

So the rule stayed absolute: if a tool can't run fully in the browser, it doesn't go on the site.

What's actually in the box

Seventy tools sounds like a lot until you list the small annoyances of a normal week:

• PDF tools – merge, split, compress, convert, add page numbers. The unglamorous workhorses.
• Image tools – a compressor, a resizer, and format converters (AVIF to JPG is the one that saves people from "why won't this file open" more than any other I made).
• Converters – the odd format translations you need once and resent installing software for.
• Calculators – age, dates, business days, BMI, calories, compound interest. Boring. Opened constantly.

My own most-opened tabs are the image compressor and the PDF compressor, in that order, most weeks. Not because they're clever – because sending a too-big attachment is a problem I personally have all the time. I suspect that's the entire secret of tools like these: the frequency of the annoyance matters more than the cleverness of the solution.

Lessons from building 70 small things instead of one big thing

1. Boring beats novel. Nobody wakes up excited about a date calculator. But "days between dates" is a question thousands of people type into Google every single day, in the exact moment they need the answer. A tool that answers in two seconds, with no sign-up wall, wins that moment against software ten times more powerful.

2. The last click is the product. Every incumbent I was frustrated with did the actual work fine – then held the result hostage at the download step. That final click is where trust is won or lost. On ToolPixi the download is just a download. Users remember who didn't mug them at the exit.

3. No account is a feature people can feel. I can't offer sync, history, or saved files – the architecture forbids it. I thought that would hurt more than it does. What I hear back instead, when people write in, is relief. In 2026, "we literally cannot see your file" lands harder than any feature list.

4. Maintenance is the real project. Seventy tools means seventy small things that can break when a browser changes behaviour, a library updates, or an edge-case file shows up with a format quirk I didn't test. Launching was a weekend-shaped problem. Owning the thing is a forever-shaped one. If you're starting something similar, budget your enthusiasm accordingly: most of the work is unglamorous fixing, and the fixing is what makes it trustworthy.

5. Ship the set, not the masterpiece. Each individual tool is almost embarrassingly simple. The value is the shelf – one bookmark that covers the whole category of "small file annoyance," so nobody has to go back to the upload-and-paywall ritual for the next one.

What I'd do differently

I'd start with the calculators. Seriously. They're the fastest to build, they answer questions people are already asking search engines, and they taught me how people actually arrive at a tool site: not through a homepage, but sideways, from a search result, straight into the one tool they need. Design for that arrival – tool first, brand later – from day one instead of learning it the slow way.

I'd also write the "your file never leaves your device" line into the design from the first sketch, not as a headline I added later. It's on the homepage now – "70 free browser tools. Your files never leave your device." – because it's the whole idea in one sentence, and everything else is implementation detail.

The other thing I run

ToolPixi isn't my only project. I also run Grab AI Tool, a directory of AI tools with the prices printed on the listings – same philosophy, different problem: be the page I wished existed, charge nothing, and don't hold the useful part hostage. Building both has convinced me the philosophy travels. Whatever you're making, there's a version of it that respects the person using it a little more than the incumbents do. That version is usually buildable. It's often even simpler. It's just rarely the default.

If you want to try the tools, they're at toolpixi.com – no account, obviously. And if you build browser-only tools too, I genuinely want to hear what you did about the big-file problem, because I still don't have an answer I'm proud of.

— Hamza Ali Basra, entrepreneur