Why your dev tools should run client-side (and what to watch out for)

Every developer has pasted a secret into an online formatter at least once. A config file with API keys. A JWT they wanted to inspect. A regex they needed to test against production data. The online tool formatted it, spat out a result, and everyone moved on. The problem: that secret is now in someone else’s database.

Modern browser runtimes can do almost everything a server can do for dev tools. JavaScript is fast. The Web Crypto API is solid. WASM means even heavy parsing (YAML, JSON Schema, regex) runs locally. The result: a new generation of dev tools that process everything client-side, never upload your data, and don’t even need a backend to operate.

This post is about why that matters, the cases where it doesn’t work, and how to spot the difference.

What “client-side” actually means

A client-side tool is one where the work happens in your browser, not on a server. The HTML, CSS, and JavaScript are downloaded once. From that point on, every operation is local. The server is no longer in the loop.

For a JSON formatter, that means:

• You paste JSON into a <textarea>.
• The browser parses it, formats it, and displays the result.
• No fetch call is made. No API endpoint. No logging service.

For a JWT decoder, it means:

• The three base64 segments are decoded in the browser.
• The signature is verified (or not) using code that runs locally.
• The secret never leaves your machine.

You can verify this yourself in any browser. Open DevTools → Network, perform the operation, and watch the request log. A truly client-side tool will show zero requests carrying your input.

Why this is better for dev tools

Privacy. The most obvious benefit. The tool provider cannot leak what they never received. They cannot be subpoenaed for logs that don’t exist. They cannot sell your data because they don’t have it.

Latency. No network round-trip. A 100KB JSON file takes a few milliseconds to format. The same file uploaded to a server, formatted, and downloaded might take 200ms on a good day. For tools you use dozens of times a day, that adds up.

Cost. The tool provider doesn’t pay for compute or storage. A client-side tool has effectively zero marginal cost per user. That’s why so many of them are free.

Offline. Once the page is loaded, the tool works without an internet connection. Useful on planes, in coffee shops with spotty wifi, and in air-gapped environments.

Resilience. The tool doesn’t go down when the provider runs out of money or decides to pivot to crypto. As long as the URL is reachable, it works.

The trade-offs

Client-side isn’t free. There are real reasons some tools can’t go this way.

File size limits. The browser tab is a single process. Very large files (hundreds of megabytes) can crash the tab. A server-side tool can stream and handle arbitrary sizes. For a JSON formatter, anything past ~50MB starts to feel sluggish in the browser. The DevSpeedTools JSON formatter handles this fine; for genuinely huge files, a streaming CLI tool is the right answer.

No collaboration. If your tool needs to share state across users — think Figma, Google Docs, multiplayer anything — you need a server. But that’s not what most dev tools do. A formatter, a validator, a decoder, a generator — all of these are single-user operations.

No analytics on user data. Providers can’t see what people are doing with the tool. That’s the point. But it also means the tool author can’t debug user-reported issues as easily. Good client-side tools provide clear error messages and a way to share reproducible examples without sharing the actual data.

Cross-origin asset restrictions. If the tool needs to fetch from a third-party API (say, a JWT verifier that needs to fetch a JWKS from an identity provider), the CORS configuration has to be right. For purely local tools, this isn’t a concern.

The initial download. WASM modules can be a few megabytes. A large WASM-based YAML parser or regex engine can take a moment to load on first visit. Subsequent visits are cached. Streaming compilation (now standard in Chrome and Firefox since 2024) means the first parse happens before the full module is downloaded, so this has shrunk from a real concern to a minor one. WebGPU, where it’s available, lets compute-heavy dev tools (image processing, crypto, regex engines) run on the GPU — orders of magnitude faster than JavaScript for the right workload.

How to verify a tool is actually client-side

The marketing copy on most dev tools says “client-side” or “in-browser” or “no upload”. Most of them mean it. Some don’t. Here’s how to check.

1. Open DevTools → Network. Use the tool. Watch the requests. If the tool is making a POST to an API with your data, it’s not client-side. If the only requests are for the HTML, CSS, and JS bundle, you’re good.
2. View source. Right-click → View Page Source. Find the JavaScript. If the heavy lifting is in a script tag and runs locally, the tool is client-side. If it’s all in a thin wrapper around a server API, the tool is not.
3. Block the network. DevTools → Network → “Offline”. Reload the tool (you’ll need the page cached). Use the tool. If it still works, the tool is genuinely client-side.
4. Read the privacy policy. Look for the line “we do not collect” or “we do not log” or “all processing happens in your browser”. A vague “we value your privacy” is a yellow flag.

What good client-side dev tools look like

The best client-side tools share a few characteristics:

• They tell you they’re client-side. Often with a small badge near the input (“Processed locally” or a lock icon).
• They work offline. Once loaded, the page keeps working with no network.
• They handle paste-large-data gracefully. A 10MB paste shouldn’t lock up the browser.
• They provide a way to share a state via URL fragment. For example, a tool that encodes your input into a #data=... URL fragment lets you share an example without sending the data to a server. The DevSpeedTools share helper does exactly this.
• They have a privacy note. A short sentence explaining what the tool does with your input — usually “nothing”.

When server-side is still the right answer

Not everything can or should be client-side:

• Tools that need a database. A “what’s my IP” tool needs to actually see your IP.
• Tools that need to call paid APIs. A “summarise this article” tool calls OpenAI. The OpenAI key can’t ship in the browser.
• Tools that need write access to external systems. Anything that posts to Slack or creates a GitHub PR.
• Tools that need to aggregate across users. A “is this domain on a blocklist” tool needs the shared blocklist.

The dividing line: if the operation is a function of the user’s input alone, it should be client-side. If the operation needs shared state, a server is unavoidable.

The shift in the dev-tools space over the last five years has been dramatic. Tools that used to require a backend (formatters, validators, decoders, generators) now run entirely in the browser. The pattern is simple: download once, run forever, send nothing. For developers who work with sensitive config or production tokens, that shift is a meaningful upgrade in safety.