Client-Side vs Server-Side Tools: Why Your Data Should Never Leave the Browser

Paste a JSON blob into a random formatting site and one of two things happens. Either the formatting runs in JavaScript on your own machine, or your JSON is sent over the network to a server you know nothing about, formatted there, and sent back.

Visually, these are identical. Legally and practically, they are not remotely the same thing.

What "client-side" actually means

A client-side tool does all its work in the JavaScript engine of your browser tab. The page loads once. After that, the data you type, paste, or drop in never crosses the network.

A server-side tool ships your input to a backend. That backend processes it, and somewhere along the way your data may be written to disk, held in memory, logged by a reverse proxy, cached by a CDN, or retained in a temp directory that nobody remembered to clean.

The modern browser is genuinely capable. Almost everything a utility site does can run locally:

That last row matters more than it looks. A password generator that runs server-side is a password generator that has, at some point, transmitted your password.

Why this is a real risk, not paranoia

The problem is not that every operator is malicious. Most are not. The problem is that server-side processing creates a liability surface that does not need to exist.

Consider what you routinely paste into online tools:

• API keys and bearer tokens, when decoding a JWT
• Production database rows, when formatting a JSON response
• Customer names, emails, and addresses, when converting a CSV
• Contracts, invoices, medical forms, when merging PDFs
• Internal source code, when using a diff checker or beautifier

A JWT is the sharpest example. The payload of a JWT is only base64-encoded, not encrypted - anyone holding the token can read it, and if it has not expired, use it. Pasting a live production token into a server-side decoder is functionally equivalent to emailing your credentials to a stranger. Decoding it requires no secret and no network call; it is pure string manipulation.

Then there are the second-order risks:

• Logging. Reverse proxies and application frameworks log request bodies by default in many configurations. Your data ends up in a log aggregator with a 90-day retention policy.
• Compliance. Under GDPR, sending personal data to a third-party processor without a lawful basis and a data processing agreement is a violation, regardless of what happens to it afterwards. The same logic applies to HIPAA and most corporate data-handling policies.
• Acquisition and breach. The privacy policy that governs your data today is the policy of whoever owns the domain today.
• Silent migration. A tool that was client-side last year can quietly become server-side after a rewrite. Nothing in the UI will tell you.

How to check any tool in 30 seconds

You do not have to take a site's word for it. Open DevTools and look.

The network test:

1. Open DevTools with F12 or Cmd+Option+I
2. Go to the Network tab and click the clear button
3. Use the tool - paste your data, click the button
4. Watch the request list

If new fetch/XHR entries appear carrying your input, it is server-side. If nothing appears beyond analytics pings, the work happened locally.

The offline test (stronger):

1. Load the page normally
2. In DevTools, open the Network tab and set throttling to Offline
3. Use the tool

A genuinely client-side tool keeps working with the network disconnected. A server-side one fails immediately. This test is hard to fake.

The payload test:

If you do see a request, click it and read the Payload tab. Sometimes the request is harmless - a font, a telemetry event, an error report. Sometimes you will find your entire input sitting in the request body.

When server-side is genuinely necessary

Client-side is not a religion. Some operations legitimately cannot run in a browser tab:

• Anything requiring a secret. Calling a paid third-party API needs a key, and a key shipped to the browser is a public key. This is why "AI" features are almost always server-side.
• Fetching arbitrary URLs. Same-origin policy blocks a browser from reading most cross-origin pages. Link checkers, SEO crawlers, and Open Graph preview tools need a server to fetch on your behalf.
• DNS, WHOIS, port scanning, SSL inspection. Browsers cannot open raw sockets.
• Very large workloads. A 4 GB video transcode will exhaust tab memory. Desktop software beats both options here.
• Persistence and collaboration. Shared, saved, or multi-user state needs storage somewhere.

The honest position is not "server-side is evil." It is that server-side should be the exception, disclosed clearly, and limited to cases where the browser genuinely cannot do the job.

What good disclosure looks like

A trustworthy tool site tells you, per tool, where processing happens. Weasel phrasing to distrust:

• "We delete your files after one hour." → They received your files.
• "Secure SSL upload." → TLS protects data in transit, not from the recipient.
• "We do not store your data." → Storage is not the only risk. Logs, memory, and third-party subprocessors are not "storage."
• "Your privacy is important to us." → Says nothing at all.

What you actually want to read is a concrete architectural claim: "This runs entirely in your browser. Disconnect your network and it will still work." That is falsifiable, and you can falsify it in 30 seconds with the offline test.

A practical policy for your team

If you work anywhere with real data, adopt something like this:

1. Never paste live credentials, tokens, or keys into any web tool. Not client-side ones either - browser extensions and shoulder surfers exist. Rotate anything you do paste.
2. Default to client-side tools for formatting, encoding, hashing, converting, and image work. There is no reason to accept network risk for a JSON.stringify call.
3. Verify with the offline test before a tool becomes part of a routine workflow.
4. Redact before you paste. Replace real identifiers with dummy values. Most debugging works fine on structurally-identical fake data.
5. Prefer local CLI tools for production data. jq, openssl, imagemagick, and qpdf cover an enormous amount of ground and never touch a network.

Where FIXR stands

Every tool on this site that can run in your browser, does. JSON formatting, image compression, hashing, and JWT decoding all execute locally - no upload step, no request body containing your data. Turn your network off and try them.

Do not take that on faith. Open the Network tab and check. That is the entire point.

Key takeaways

• Client-side means your data never leaves the tab; server-side means it was transmitted to someone else's machine
• Modern browser APIs handle hashing, images, PDFs, compression, and crypto natively
• JWTs, API keys, and customer data are the highest-risk things people routinely paste into random sites
• The offline test in DevTools proves client-side processing in about 30 seconds and is hard to fake
• Server-side is legitimate for secrets, cross-origin fetches, raw sockets, and very large jobs - but should be disclosed
• "We delete your files after an hour" is a confession, not a privacy guarantee