Why I Built a Free Tools Site That Doesn't Track You
Published February 1, 2026 · 10 min read
Two months ago I needed to format a 4MB JSON file. I pasted it into the top Google result for "JSON formatter." Within seconds, my data was on someone else's server. I have no idea what they did with it. Their privacy policy was 4,000 words long. Their actual data handling was probably fine. I don't know, and neither do you, and that's the point.
That was the day I started building OnlineToolsPro. Not because I had a grand vision. Because I was tired of pasting my data into strangers' servers for tasks that didn't require a server at all.
This post is about why I made the choices I made, and why I think browser-based tools are the future of personal computing for most of what we do online.
The Cloud Tool's Hidden Cost
Most "online tools" follow a simple pattern: your input gets uploaded to a server, the server processes it, the result gets sent back. The interface looks like it's doing work in your browser, but under the hood, your data is making a round trip to a data center somewhere.
For some tools, that's necessary. You can't render a PDF or transcribe audio in a browser efficiently. You can't train a machine learning model on a phone. Heavy compute needs a server. Cloud tools for those tasks make sense.
But for most "utility" tools — the long tail of formatting, converting, generating, comparing, validating — the cloud is doing work that the browser could do. It's slower (network round trip), more expensive (server costs), and a privacy risk (your data is in someone else's hands). The cloud is the wrong architecture for these tasks, but it's the default because it's easier to build.
When you build a tool in the cloud, the architecture is simple: a frontend that takes input, a backend API that processes it, a database to store it. You can ship in a weekend. You can scale to millions of users with managed services. You can add features without rewriting the core.
When you build a tool in the browser, the architecture is harder: a single page that loads some JavaScript, runs it locally, and never talks to a server. You have to handle weird browser quirks, you can't store user data, you can't iterate on features without a deploy, and you have to deal with the fact that "no data leaves the browser" means you can't track usage either.
It's harder. I built this site and I can tell you: every single decision was harder than it would have been with a cloud backend. The trade-off is that when the page loads, the tool works. No waiting. No server. No trust required.
What "Client-Side" Actually Means
Let me be specific. A client-side tool has these properties:
The processing happens in your browser. The JavaScript that does the work runs on your CPU, not on a server. Your input never leaves the page.
The tool can work offline. Once the page is loaded, the JavaScript is cached. You can disconnect from the internet and the tool keeps working. This is genuinely useful on planes and trains.
No user accounts are required. The tool doesn't need to identify you because it doesn't need to remember anything about you. There's no "free tier with limits, premium for unlimited" because there's no server to limit.
The tool is auditable. You can view source. You can see the JavaScript that's running. If it sends data anywhere, you'll see the network request in your browser's DevTools. Cloud tools require trust; client-side tools can be verified.
Failures are local. If the tool has a bug, it fails for you, on your machine. There's no "our server is down" message. There's no data loss because there was no data being stored.
The downside is that you can't do things that need coordination across users. You can't build a real-time collaborative editor this way. You can't do server-side search across a large index. You can't do anything that requires the data of multiple users in one place. For those, the cloud is the right answer.
But for the 80% of tools I actually need — format this, convert that, generate something, compare two things — the cloud is overkill.
How to Verify a Tool is Actually Client-Side
This is the part I think most people miss. The site says "we don't store your data" in the privacy policy. But how do you know? Here's how to check in 30 seconds:
Open your browser's DevTools (F12 or Cmd+Opt+I). Go to the Network tab. Filter by "Fetch/XHR" to exclude static assets. Then use the tool.
If the tool is truly client-side, you won't see any new network requests after the initial page load. The tool is just JavaScript running locally. The network tab stays quiet.
If the tool is uploading your data, you'll see a request go out when you click "submit" or "format" or whatever. The request will contain your input as a POST body or a query parameter. The server's response will be the result.
For my tools, the network tab is silent. There's nothing to upload because the work is happening locally. I encourage you to verify this on any tool you use, not just mine.
Why This Matters More Than It Used To
Ten years ago, the argument for cloud tools was stronger. Browsers were slow. JavaScript was slow. Doing real work in a browser felt like swimming through molasses. For a JSON formatter, the difference between 200ms (cloud) and 2 seconds (browser) was enough to make the cloud version the obvious choice.
That's not true anymore. Modern browsers are fast. V8, SpiderMonkey, and WebKit's JS engines are highly optimized. WebAssembly lets you run near-native code in the browser. For most utility tasks, the browser is now the fastest place to do the work, because the network round trip is the slowest part of the process.
For a JSON formatter processing 4MB of data:
- Cloud tool: upload (1-2 seconds over typical broadband) + process on server (50ms) + download (1-2 seconds) = 2-4 seconds total
- Client-side tool: load page (200ms, one time) + process locally (300ms for 4MB JSON parse) = 500ms total
The cloud tool is 4-8x slower for the same result. And the client-side tool didn't need to upload your data anywhere.
That's the opposite of the conventional wisdom. The conventional wisdom says "cloud is faster because it has more compute." For most utility tasks, the conventional wisdom is wrong. The bottleneck isn't compute, it's network.
What I Gave Up to Build It This Way
Building a no-server tools site has real costs. Let me be honest about them so you can decide if the trade-off is worth it for your own work.
No analytics. I don't know what tools people use, how often, or what they do with them. I can't see which features are popular, which pages have high bounce rates, or which blog posts get read. I have to make product decisions based on intuition and feedback, not data. That's a real disadvantage.
No accounts, no logins. Every tool is anonymous. I can't offer saved preferences, history, or sync across devices. If you want to save your work, copy it to a file or use the browser's local storage (which I'm not using for this site).
No server-side processing for hard problems. If you need to convert a 500MB file, the browser will struggle. The cloud would handle it. I could add a server for that one tool, but that breaks the principle. For now, the tools are sized for "things you'd put in a text field or paste from a document." Anything bigger and you should use a different tool.
SEO is harder. I can't generate dynamic content based on user behavior. Every page is the same for every visitor. I can't A/B test headlines. I can't personalize the experience. For a content site, that's a disadvantage. For a tools site, it's fine because the tools work the same for everyone.
Updates are all-or-nothing. I can't ship a fix to one user while others stay on the old version. Every change deploys to everyone immediately. That's good for security (no version lag) and bad for stability (no gradual rollout).
What I Gained
The trade-offs are real, but the gains are too.
No data breach risk for users. There's no server holding your data, so there's no server that can be breached. The worst case is that the static site itself gets defaced, and the hosting provider's audit logs would show that.
No subscription, no premium tier, no upsell. The site is free because the marginal cost of serving a static page is effectively zero. I don't need to monetize your data because I don't have it. The "free because you're the product" model doesn't apply when the product doesn't collect you.
No legal exposure. GDPR, CCPA, HIPAA, COPPA — all of these are about data handling. When you don't handle data, most of those rules don't apply. There's no privacy policy to write because the policy is "we don't have your data."
Instant load times. A static site on a CDN is fast everywhere. No database queries, no server-side rendering, no API calls. The page loads, the tool works.
The site works on a plane. I actually use the tools on flights. I open the JSON formatter offline, paste a response I got before boarding, and format it. That's a small thing but it's a real benefit.
Who This Model Doesn't Work For
I'm not arguing that every tool should be client-side. There are real limits:
Heavy compute. Video encoding, image processing at scale, ML inference, large dataset analysis — these need a server. Your laptop can't compete with a GPU cluster for these tasks.
Cross-device sync. If you need your data to follow you across phone, laptop, and tablet, you need a server. Local storage is per-device, and cross-device sync is hard to build without a backend.
Collaboration. Real-time multi-user editing, shared documents, team features — these need a server to coordinate state across users.
Large reference data. Search engines, language translation, maps — these need access to large datasets that don't fit in a browser cache.
For all of these, the cloud is the right answer. I'm not anti-cloud. I'm pro-appropriate-architecture. The cloud is great when you need it. It's wasteful and risky when you don't.
How to Build Your Own
If you're building a tool and you're not sure whether to go cloud or local, here's a quick decision tree:
Can you do the work in JavaScript on a typical user's machine in under 5 seconds? Go local. The privacy story is better, the performance is better, the costs are lower.
Does the work require data the user doesn't have (a search index, a translation model, a database of known files)? Go cloud. There's no way around it.
Does the work need to be coordinated across users or devices? Go cloud. The architecture has to support it.
For everything else — and this is most utility tools — the answer is local. The work is faster, the user trusts you more, and you don't have to write a privacy policy that explains what you do with their data.
Try the Tools
Browse OnlineToolsPro and use any of the 37 tools. Watch the network tab. Notice that nothing leaves your browser. Notice how fast they are. Notice that the page works offline after the first load.
That's the whole point. Tools that respect your privacy, run fast, and work when the network doesn't. The web can do this. The web should do this. Most of the web doesn't, but more of it will, and I want to be part of making that happen.
How I Verify My Own Site Stays Client-Side
It's easy to accidentally add a server dependency. A third-party analytics script, a font loader, a CDN-hosted library that phones home. Every time I add a feature, I check the network tab. If the new feature requires data to leave the browser, I either find a client-side alternative or I don't add the feature.
The discipline is worth it. It means I don't have analytics, which is a real cost. I don't know what tools people use most, what features they struggle with, what they'd want me to build next. I have to rely on direct feedback and intuition, which is harder than data. But the alternative — adding even a single network call to "just track usage" — would compromise the principle that the site is supposed to demonstrate.
You can verify this yourself. Open the network tab in DevTools, use any tool on this site, and watch. The only requests are the initial page load and the static assets (CSS, JS, fonts). Once the page is loaded, your data stays on your machine. That's the contract.
What I'd Tell a Developer Considering This Approach
If you're building a tool and considering the client-side approach, here's the honest advice:
Start client-side, escalate to cloud only if necessary. It's easier to add a server later than to remove one. The default should be local. If the work needs a server, the architecture will tell you.
Learn the browser APIs. IndexedDB, Service Workers, the File System Access API, Web Workers, WebAssembly. These are the tools that make client-side work practical for non-trivial applications. Investing time in them pays off across every project you build.
Budget for offline support. If you can get the tool working offline, you've also made it work in poor network conditions, on planes, and in regions with limited connectivity. That's a feature your users will notice and appreciate.
Don't track everything. The pull to add analytics is strong. Resist it. Every byte of data you collect is a liability. If you can build the product without analytics, you'll have a better product and a clearer conscience.
Publish your source. If you're building a tool that handles user data, publish the source code. It doesn't have to be open source under a specific license, but it should be inspectable. The cost is low; the trust benefit is enormous.
The Web I Want to Live In
I want a web where the tools I use don't track me. Where the page loads in under a second. Where my data stays on my device unless I explicitly choose to share it. Where the network is a convenience, not a dependency. Where "no data leaves your browser" is a feature, not a marketing claim.
That web is technically possible today. The browser APIs are there. The performance is there. The privacy story is there. What's missing is the will to build it that way, because the cloud is easier and the analytics are seductive and the unit economics favor tracking.
I'm one person building one site. I can't fix the whole web. But I can build a corner of it that works the way I think the web should work, and I can show that it's possible. If enough people do that, the web gets better. That's the bet. So far it's holding up.