Why I Build Everything Client-Side
Every tool on BoltQuickTools runs entirely in your browser. There is no upload step, no server-side processing, no analytics watching what you paste. This is not a marketing posture I retrofitted onto a backend product. It is the original constraint I imposed on myself when I started the site, and over the past few months I have been asked enough times to explain why that I figured it was worth writing down properly.
This essay is half philosophy and half implementation notes. If you skim it, the headline is: client-side tools are faster, safer, and cheaper to operate than the server-side equivalents, but they impose real constraints on what is possible. Knowing those constraints is the difference between a tool you trust and a tool that just looks trustworthy.
The moment that decided the architecture
In early 2026 I was debugging a flaky API integration at my day job and needed to decode a JWT to inspect the claims. I opened the first JWT decoder Google returned. I pasted the token. The page sent the token to a server, where it was decoded and returned. The token included a customer's session ID and email. I had just leaked a customer's PII to an ad-supported tool site I had never heard of, and the only reason I knew it had happened was because I had the Network tab open.
I closed the tab, rotated the customer's session, and spent the rest of the afternoon writing my own JWT decoder as a single HTML file. That was the first tool. The decision to keep everything in the browser was not philosophical at first; it was a direct reaction to that incident. Once I built the second tool the same way, it became a rule. Once I built the tenth, it became a brand.
What "client-side" actually means here
The phrase gets thrown around loosely, so it is worth being precise about what BoltQuickTools actually does on the client. There are three layers:
- Static page delivery. An nginx container behind Cloudflare serves a single HTML file per tool. The server has no idea what the user does after that file lands.
- In-browser computation. Every tool uses standard Web APIs (Canvas, Web Crypto, FileReader, CompressionStreams, TextEncoder, etc.) and a small amount of hand-written JavaScript. There is no remote function call for the actual work.
- Local persistence. Some tools save preferences (recent tools, randomizer counters, language choice) in localStorage. Nothing leaves the browser.
You can confirm the second layer with five seconds of work: open DevTools, switch to the Network tab, then use any tool. If a tool sends your data to a server, you will see the request. If it does not, you will see nothing. The cookie-consent banner and ad scripts make outbound requests, but no user-entered data does. That is the property I optimize for.
Why this architecture is faster than a backend
The intuitive assumption is that a server with optimized native code will outrun browser JavaScript. For small inputs, that is empirically wrong. Here is why:
The total time a user experiences is round-trip latency plus processing time. A typical home internet round-trip to a US server is 30 to 100 ms. A round-trip to a server on a different continent is 150 to 300 ms. For a JSON formatter operating on a 50 KB payload, the actual formatting takes under 5 ms in V8. The server-side version is always slower than the client-side version because the network round-trip dominates.
This holds up to surprisingly large inputs. The breakeven point where a server outperforms the browser is around a few megabytes of data, and only if the server is geographically close. For everything BoltQuickTools handles, the browser wins.
Why this architecture is safer than a backend
Three reasons, each of which I have personally watched bite people:
1. There is no breach surface for user data. The most common privacy disaster for tool sites is "we logged the inputs for debugging and then the logs leaked." It is impossible for me to leak data I never received. The static file server logs IP and User-Agent for security reasons, but it never sees your JSON, your image, or your password.
2. There is no insider risk. If you upload a sensitive PDF to a server, someone at that company can read it. Maybe the policy says they will not. Maybe they actually will not. You are still trusting them. Client-side tools remove that question entirely.
3. There is no compelled-disclosure risk. A subpoena cannot extract data the server never had. This is mostly relevant for journalists and activists, but it is true for everyone: a tool that does not have your data cannot be forced to hand it over.
The honest trade-offs
I would be selling you a bridge if I said client-side tools were strictly better. Here is what they give up:
1. Heavy computation is harder
Browsers cap how much memory a tab can use and how long a single function can run before the browser declares it unresponsive. Tools that need significant horsepower (large image processing, video transcoding, deep neural network inference) bump into these limits. BoltQuickTools' image upscaler uses an ONNX model that runs in the browser via WebAssembly, but the model is a tradeoff: small enough to fit in memory, big enough to look better than a Lanczos resize. A server with a real GPU would do this in a tenth of the time.
2. No cross-device sync
If you want your tool history available on your phone after using the desktop tool, a backend is the only realistic answer. BoltQuickTools' "recently used tools" feature only works on the same browser profile because the data lives in localStorage. I have decided that is the correct trade.
3. Confidence-of-correctness is harder to communicate
A user who pastes a private SSH key into a hash generator has to trust me that the JavaScript on the page is not exfiltrating it. They can verify with DevTools, but most users will not. The trust comes from reputation and source transparency. With a server-side tool, users can at least point at a privacy policy. With a client-side tool, the privacy policy is the source code itself, and most users do not read source.
The tools where this matters most
For a JSON formatter the architecture is mostly a performance win. For other tools, the privacy benefit is the entire point:
- Basic auth header generator: you are by definition handling credentials. Sending them to a server to encode them is absurd.
- Hash generators: people use these to hash passwords for one-off verification. The password should never touch a wire.
- Image to Base64: people convert personal photos. Why would the photos leave the device?
- EXIF viewer: the whole point of the tool is privacy awareness. Uploading the image first would be ironic.
- JWT decoder: same lesson as my opening anecdote.
How I think about new tools
When someone emails me a tool suggestion, the first question I ask is: can this run entirely in a browser? If the answer is no, I usually do not build it. There are exceptions where I add a tool that needs a third-party CDN (the OCR tool fetches a Tesseract WebAssembly bundle, for example), but those CDNs serve binary assets, not user data, and the user can audit the request.
The second question is: is the value of a client-side version actually better than the cloud equivalent? For an HTTP status code lookup, the answer is no; a static page that does not even need JavaScript is fine. For a code diff, the answer is a strong yes, because nobody should be pasting source code into a stranger's server.
What this means for you
If you take one thing away from this essay: when you find a developer tool online, open the Network tab before pasting anything sensitive. Not because the tool is necessarily malicious, but because it is your data and you should know where it goes. The Network tab is the most honest test of any privacy claim.
And if you want the BoltQuickTools approach in one sentence: I do not want your data, I do not need your data, and I have built the architecture so that I literally cannot accidentally get your data. The site is small, the bill is low, and the tradeoff has been entirely worth it.