Years of doing WordPress plugin support taught me a bad habit. A customer sends you a broken serialized options blob, you need to read it now, so you paste it into the first online unserializer Google gives you. I did this for a long time without thinking about it — until the day I looked at what I'd just pasted. It was a customer's wp_options export. It contained their SMTP password, a Mailchimp API key, and a license key. All of it had just been POSTed to a server I knew nothing about, run by someone I couldn't name, in a country I couldn't guess.
Nothing bad happened, as far as I know. That's the unsettling part — I have no way to know. There's no notification for "your paste got logged." The data either sat in someone's access logs or it didn't, and I'll never find out which.
That incident is a big part of why toolz.dev works the way it does. Every one of the 50 tools on the site processes your input in your browser. Not "we promise we delete it after processing" — it never gets transmitted in the first place. This guide explains the difference between those two architectures, why it matters more for developers than for almost anyone else, and how to verify a tool's claims yourself in about 30 seconds. And, since I did eventually paste that customer blob somewhere safe, the PHP Unserializer that replaced my bad habit.
TL;DR: Server-side tools transmit your input to someone else's machine, where it can be logged, retained, breached, or shared — and you can't verify any of it. Client-side tools ship you the code and process everything locally; verification takes one DevTools Network tab check. For anything containing credentials — JWTs,
wp-configvalues, connection strings, API responses — use client-side tools like the JSON Formatter, JWT Decoder, SQL Formatter, and YAML Validator. Everything on toolz.dev runs in the browser.
What Actually Happens When You Paste Into an Online Tool?
There are exactly two architectures, and every online tool uses one of them.
Server-side: your input travels from your browser to the tool's server, gets processed there, and the result travels back. Five steps, and your data exists on someone else's infrastructure during three of them.
Your browser → network → their server → network → your browser
(input) (transit) (processing, (transit) (result)
logging?,
retention?)
Client-side: your browser downloads the tool's JavaScript once, and then everything — input, processing, output — happens in a tab on your machine. The only thing that ever crossed the network was the code.
Their server → your browser
(code) (input + processing + result, all local)
The distinction sounds academic until you list what can happen to data on a server you don't control. It can land in access logs and application logs. It can be captured by error trackers like Sentry, which snapshot request context when something throws. It can be retained in backups long after the operator "deleted" it. It can be read by any employee with log access. It can be swept up in a breach. And with several "free tool" operators, it can be the actual product — monetized through analytics or sold as training data.
None of these require malice. Default logging configurations alone will do most of it. The operator of that unserializer I used probably never looked at my customer's SMTP password. But "probably" is not a security posture.
Why Is This a Bigger Deal for Developers Than for Anyone Else?
Because of what we paste. An average user pastes a paragraph of text into a word counter. A developer pastes:
API responses with live tokens. You're debugging an integration, you copy the whole response — headers included — and format it to read it. That Authorization: Bearer ... header just went wherever the formatter lives. GitGuardian's State of Secrets Sprawl research found about 12.8 million secrets exposed in public GitHub commits in 2023 alone. Nobody publishes equivalent numbers for online tools, because unlike GitHub, tool operators' logs aren't publicly scannable. That's not reassuring — it means the leak surface is invisible.
JWTs. A JSON Web Token is base64url-encoded, not encrypted — RFC 7519 is explicit about this. The payload of every token you paste into a server-side decoder hands over the user's ID, email, roles, and expiry. If the token is still valid, you've potentially handed over a working session credential. Decode them locally with the JWT Decoder instead.
SQL with real data in it. The query you're formatting has a WHERE email = '[email protected]' clause in it, and the table names sketch your whole schema. The SQL Formatter keeps that in your tab.
Config files. wp-config.php values, .env contents, Kubernetes manifests, database.yml — configuration is where credentials live. I've validated YAML files that contained every secret my Laravel app had. That's a paste you want going through a client-side YAML Validator, not a form POST.
Serialized WordPress data. My personal downfall, per the intro. WordPress stores options and metadata as PHP-serialized strings, and debugging them means unserializing them — the PHP Unserializer does it without your customer's data leaving your machine.
One careless paste from any of these categories is a security incident that nobody will ever detect, report, or clean up.
How Do You Verify a Tool Is Actually Client-Side?
This is the part I like most about client-side architecture: you don't have to trust anyone's privacy policy. The claim is mechanically verifiable.
- Open the tool's page.
- Open DevTools (F12) → Network tab. Check "Preserve log."
- Paste in some recognizable test data —
MY-SECRET-TEST-12345works — and run the tool. - Watch the request list.
If the tool is client-side, you'll see the initial page load and static assets, and then nothing when you process. If a request fires when you hit the convert/format/process button, filter the requests and inspect the payloads for your test string. Found it? Server-side. Done — that took half a minute, and you now know more about that tool than its privacy policy would ever tell you.
Two honesty notes about toolz.dev, because this cuts both ways. First, the site does load analytics for page-view counts and does track that a tool was used — for usage limits — but never what you put into it. Run the Network check yourself; the input never appears in any request. Second, client-side has a real limitation: your browser does the work, so a 4 GB video transcode isn't happening in a tab. For the formatter/converter/encoder category of tools, though, modern JavaScript is more than fast enough — usually faster than server-side, because there's no upload round-trip at all.
Server-Side vs Client-Side: The Straight Comparison
| Server-side tools | Client-side tools | |
|---|---|---|
| Where processing happens | Operator's server | Your browser |
| Data transmitted? | Yes, every time | No — only the tool's code is downloaded |
| Can be logged/retained by operator | Yes, often by default | No — operator never receives it |
| Exposed in a breach of the tool | Yes, if retained | No |
| Verifiable by you | No — you trust the policy | Yes — DevTools Network tab, ~30 seconds |
| GDPR processor agreement needed | Yes, if personal data (Art. 28) | No processing by a third party occurs |
| Works offline after load | No | Often yes |
| Speed for typical dev tasks | Upload + queue + download | Instant — no network round-trip |
| Heavy computation (video, huge files) | Better suited | Limited by your device |
What Does GDPR Say About This?
I'm a developer, not a lawyer, so treat this as engineering context rather than legal advice — but the outline matters for anyone who handles EU user data.
Under Regulation (EU) 2016/679 (GDPR), if you take personal data — a customer's support export, an API response with user records — and push it through a third party's server, that third party is processing personal data on your behalf. Article 28 says that requires a data processing agreement. Ask yourself how many free online formatters offer a DPA. I have never seen one.
Client-side tools sidestep the whole question, not through clever legal drafting but through architecture: no data reaches the provider, so there is no third-party processing to paper over. Data minimization (Article 5(1)(c)) is satisfied in the most literal way possible — the amount of your data the provider collects is zero. The same logic helps with HIPAA (health data never reaches a non-compliant server), SOC 2 audits (no unvetted subprocessor in the data path), and PCI DSS.
To be clear: using client-side tools doesn't make your product GDPR-compliant. It removes one specific and surprisingly common leak in your development workflow — the one where a developer, trying to be helpful on a support ticket, pastes personal data into a random website.
Which Tasks Should Never Touch a Server?
My personal triage, sorted by how much a leak would hurt:
Never server-side — contains or implies credentials:
- Formatting API responses and payloads: JSON Formatter
- Decoding tokens: JWT Decoder, Base64 Converter
- Formatting queries: SQL Formatter
- Validating configs: YAML Validator
- Debugging WordPress data: PHP Unserializer
- Hashing and comparing values: Hash Generator
- Generating credentials: Password Generator, UUID Generator
Strongly prefer client-side — proprietary but not secret:
- Diffing internal code or contracts: Text Diff, JSON Diff
- Testing regex against production log lines: Regex Tester
- Converting timestamps out of logs and tokens: Timestamp Converter
- Compressing internal screenshots: Image Compressor
Low stakes, but client-side is still just faster:
- Word counts: Word Counter
- Placeholder text: Lorem Ipsum Generator
- Colors and gradients: Color Picker, Gradient Generator
There's a longer walkthrough of the full toolbox in the developer productivity tools guide and the coding tools guide.
If you genuinely need a server-side tool — a heavy conversion with no local alternative — sanitize first. Swap real keys for YOUR_API_KEY, real emails for [email protected]. It's 60 seconds of find-and-replace that turns a potential incident into a non-event.
Why Are Most Online Tools Server-Side Anyway?
Partly history, partly incentives. In 2010, browsers weren't up to the job — heavy processing had to happen on a server. That constraint is gone: modern JavaScript engines and WebAssembly handle formatting, conversion, hashing, and image compression at speeds indistinguishable from native, and browser APIs (File, Canvas, Web Crypto) cover the I/O.
The incentives are the stickier problem. Server-side processing lets an operator see usage in detail, enforce limits precisely, keep the processing logic proprietary, and — in the worst cases — treat the data itself as revenue. A tool that never receives your data can't monetize your data, which is precisely why some operators don't want the architecture even though it's now technically easy.
When I built the tools for toolz.dev, client-side was actually the simpler engineering choice, not just the more private one: no processing servers to scale, no uploads to secure, no retention policy to write, and every tool works identically in the web app and the desktop app because the logic is plain platform-agnostic TypeScript. The privacy story and the engineering story point the same direction. It's rare when that happens; take the win.
Frequently Asked Questions
What does "client-side processing" actually mean?
All computation happens in your browser, in JavaScript (or WebAssembly), on your device. The server's only role is delivering the tool's code when the page loads. Your input never appears in any network request, which you can confirm in the DevTools Network tab.
How do I check whether a tool is client-side?
Open DevTools (F12) → Network tab, enable "Preserve log," paste recognizable test data into the tool, and process it. If no request containing your test string fires, the tool is client-side. On Chrome you can also switch DevTools to "Offline" after page load — a true client-side tool keeps working.
Are client-side tools slower than server-side ones?
For typical developer tasks, they're faster — there's no upload, no queue, no download. Processing a 2 MB JSON file locally is near-instant, while a server round-trip adds latency at every step. The exception is heavy computation (large video transcodes, gigabyte-scale files), where a powerful server beats a browser tab.
Does toolz.dev collect anything at all?
Page-view analytics and anonymous per-tool usage counts (used for rate limits) — but never the content you process. Input, output, and uploaded files stay in your browser. This is verifiable with the Network tab check rather than something you have to take on faith.
Is pasting a JWT into an online decoder really risky?
Yes, more than most developers assume. Per RFC 7519, JWT payloads are encoded, not encrypted — anyone holding the token can read the claims, and if the token hasn't expired, it may be usable as a live credential. Pasting one into a server-side decoder transmits a possibly-valid session token to an unknown third party. Use a client-side decoder.
Does using client-side tools make me GDPR compliant?
No single tool choice makes you compliant. What client-side tools remove is one specific risk: personal data from your systems reaching an unvetted third-party processor (which would require an Article 28 data processing agreement you almost certainly don't have with a free tool site). Your own product's obligations are unaffected.
Can my employer see what I process in client-side tools?
Network monitoring sees which sites you visit, not what you type into a client-side tool — there's no request carrying your input to observe. Endpoint monitoring installed on the device itself (screen capture, keyloggers) sees everything regardless of tool architecture, so the honest answer is: not via the network, possibly via the endpoint.
What if there's no client-side alternative for my task?
Sanitize before pasting: replace credentials with placeholders (YOUR_API_KEY), swap real personal data for dummy values, strip hostnames and internal URLs. Then check the tool's privacy policy for logging and retention language, prefer open-source tools you can inspect, and treat "free, closed-source, server-side" as the highest-risk combination.
What is the difference between client-side and server-side tools?
Client-side tools ship code to your browser and run it there; server-side tools ship your data to a machine you don't control and run it there. Functionally the output can be identical — the difference is entirely about who ends up holding your input. With a server-side tool your data exists, however briefly, on someone else's disk, in their logs, and in their backups.
Are online JSON formatters and beautifiers safe to use?
It depends on the implementation, not the category. Formatting JSON is trivial to do in JavaScript, so a client-side formatter has no reason to transmit anything — and the Network tab check settles it in ten seconds. Be more careful than usual here, because the JSON developers paste into formatters is disproportionately API responses containing tokens, email addresses, and internal IDs.
