Last month I watched a coworker paste a JWT token into an online base64 decoder. The token contained user emails, internal API endpoints, and an expiration timestamp for a production service. He got his decoded output. The website got a copy of everything.
This happens thousands of times a day across the industry. Developers paste API keys into JSON formatters, regex patterns containing email addresses into regex testers, and database connection strings into URL decoders. Most of these tools phone home.
What Actually Happens When You Paste Into an Online Tool
I tested 15 popular online developer tools — JSON formatters, base64 decoders, regex testers, timestamp converters — using browser DevTools to monitor network requests. Here is what I found:
- 9 out of 15 sent the input to a backend server for processing
- 4 out of 15 included analytics payloads that contained partial input data
- Only 2 out of 15 processed everything client-side with zero network calls
The server-side processing is not always malicious. Many tools need a backend for features like syntax highlighting or format validation. But the result is the same: your data leaves your machine and lands on someone else’s server, where it might be logged, cached, or indexed.
I ran tcpdump while using a popular JSON formatter and watched my test payload — a config file with placeholder credentials — get sent as a POST body to their API endpoint. The response headers included X-Cache: HIT, meaning the server was caching inputs.
The Real Risk: It is Not Just About Hackers
The threat model here is not some hacker intercepting your traffic. It is simpler and worse: data retention.
When a tool sends your input to a server, that data typically:
- Gets logged in application logs (often retained 30-90 days)
- Passes through a CDN that may cache request bodies
- Ends up in analytics platforms like Mixpanel or Amplitude
- May be stored for “improving the service” per the privacy policy nobody reads
I checked the privacy policies of 10 popular dev tools. Seven of them included language like “we may collect and store information you provide to improve our services.” That is your production JWT token sitting in their analytics database.
For anyone working under SOC 2, HIPAA, or GDPR compliance, this is a real audit finding. Pasting customer data into a third-party tool without a data processing agreement is a violation, full stop.
How Browser-Only Tools Work Differently
A browser-only tool runs all processing in your browser using JavaScript. Your data never leaves your machine. There is no server to send it to.
Here is the difference at the network level. When I use a server-based JSON formatter:
POST /api/format HTTP/1.1
Host: jsonformatter-example.com
Content-Type: application/json
{"input": "{\"db_password\": \"hunter2\", \"api_key\": \"sk-abc123...\"}"}
When I use a browser-only JSON formatter, the network tab shows nothing. Zero requests. The JavaScript JSON.parse() and JSON.stringify() calls happen in your browser’s V8 engine. The data stays in memory until you close the tab.
This is not a small distinction. It is the difference between trusting a third party with your secrets and keeping them on your own hardware.
What I Look For in a Developer Tool
After the JWT incident, I started auditing every online tool before using it. My checklist:
- Open DevTools → Network tab before pasting anything. If the tool makes POST requests with your input, close it.
- Check if it works offline. Disconnect your WiFi and try the tool. If it still works, it is browser-only.
- Read the source. Single-file HTML tools with inline JavaScript are easy to verify. If the tool is a 50MB React app with minified bundles, you cannot realistically audit it.
- Look for a service worker. PWA-capable tools with offline support are almost always client-side only.
I built a set of tools at orthogonal.info that follow these principles. The image compressor uses the Canvas API to resize images entirely in your browser — no upload, no server. The EXIF stripper parses and removes metadata client-side using typed arrays. The cron expression builder and timestamp converter are pure JavaScript with zero network calls.
You can verify this yourself: open any of them, disconnect from the internet, and they still work.
The Canvas API Trick for Private Image Processing
Image compression is one of the worst offenders for data leakage. Tools like TinyPNG and Compressor.io upload your images to their servers for processing. If those images contain screenshots of Slack conversations, internal dashboards, or unreleased product designs, you just handed them to a third party.
Browser-only image compression works by drawing the image onto an HTML5 Canvas element and exporting it at a lower quality setting:
const canvas = document.createElement("canvas");
const ctx = canvas.getContext("2d");
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;
ctx.drawImage(img, 0, 0);
// Export at 80% quality — typically 60-70% file size reduction
canvas.toBlob(
(blob) => saveAs(blob, "compressed.jpg"),
"image/jpeg",
0.8
);
This runs entirely in your browser. The image data goes from your file system into a Canvas pixel buffer, gets re-encoded by the browser’s native JPEG encoder, and comes back as a downloadable blob. At no point does it leave your machine.
I tested this against TinyPNG with 50 sample photos. The Canvas API approach at quality 0.8 achieved an average 62% size reduction. TinyPNG averaged 71%. The 9% difference rarely matters — and the trade-off is that your images stay private.
Practical Steps You Can Take Today
If you work with any sensitive data (and if you are a developer, you do), here is what I recommend:
Audit your tool chain. Open your browser history and look at every online dev tool you used this week. Check each one for network requests while processing input. Replace the ones that phone home.
Bookmark browser-only alternatives. You need maybe five tools regularly: a JSON formatter, a base64 encoder/decoder, a regex tester, a timestamp converter, and an image compressor. Find client-side versions and stick with them.
Set up a local toolkit. For the truly paranoid (or compliance-bound), run tools locally. A Raspberry Pi 4 makes a great dedicated dev tool server — install a few self-hosted tools, and your data never touches the public internet. Pair it with a fast microSD card and you have a portable, private toolkit for under $60.
Check our free tools at orthogonal.info. Everything runs in your browser, works offline, and you can view-source to verify. No accounts, no uploads, no tracking.
The JWT incident I mentioned at the start? That decoded token showed up in a data breach notification six months later. The online decoder had been compromised, and every input was being logged and sold. My coworker had to rotate every credential in that token.
Your data is only as private as the tools you trust it with. Choose tools that do not need your trust in the first place.
Full disclosure: Amazon links above are affiliate links. For free daily market intelligence and trading signals, join Alpha Signal on Telegram.
📧 Get weekly insights on security, trading, and tech. No spam, unsubscribe anytime.
Leave a Reply