Engineering teams put real effort into security: least-privilege IAM roles, dependency audits, multi-factor authentication, reviewed configuration changes. Then, in the middle of a production incident, someone pastes a JWT or a minified API response into the first online decoder a search turns up.
It’s an understandable shortcut. The web tool takes ten seconds and a local script takes ten minutes. But pasting into an unfamiliar tool means trusting an unfamiliar server with whatever you pasted, and you usually have no idea what that server keeps.
This post covers where the risk comes from and how to check a tool before you trust it.
The Three Attack Vectors of Web Utilities
When you use an online utility, your data is exposed to three distinct risk categories:
1. Unintended Server-Side Persistence
Most web utility operators aren’t malicious, and many run genuinely useful services. The risk usually comes from convenience features rather than intent. To support features like “Save Snippet,” “Generate Share Link,” or simply to measure usage, some of these sites store raw request bodies in a database. If those stored snippets aren’t protected by authentication or access control, user-submitted secrets can end up discoverable by web scrapers and search engine indexers.
(For a technical teardown of how this exact flaw exposed thousands of secrets saved on popular formatting sites, see my write-up of the JSON formatter security risk).
2. Analytics and Session Replay Exfiltration
Free online utilities often sustain themselves through ad networks and analytics packages. Session replay tools in particular are designed to record user behavior. Unless the tool developer explicitly configures DOM masking rules, these scripts can capture input field contents and keystrokes and send them to third-party telemetry collectors.
3. Supply-Chain and Dependency Compromise
A utility might be completely safe when you first bookmark it. But if the maintainer pulls in an unpinned npm package that gets hijacked, or an ad network serves a malicious script tag, any code executing in that page context can exfiltrate your form inputs.
Server-Side vs. Client-Side: The Network Reality
Why client-side execution is safer comes down to where your data travels.
Traditional Server-Side Architecture
In a standard web utility, your browser mainly acts as a display layer:
When you click “Run” or “Format,” your raw data is bundled into an HTTP payload and sent over the public internet to a remote server. You have zero visibility into whether that server is logging request bodies, caching inputs in Redis, or forwarding errors to a cloud telemetry service.
Pure Client-Side Architecture
In a zero-trust, client-side utility, the processing pipeline never crosses a network boundary:
The transformation executes entirely within your browser tab’s local memory heap. The data is parsed, transformed, and displayed locally. No remote server is involved, no API calls are dispatched, and no external cache is created.
How to Audit Any Developer Tool in 30 Seconds
Don’t trust a web tool just because its homepage says “private” or “100% client-side.” You can check the claim yourself with the DevTools already in your browser.
1. The Network Tab Inspection
- Open your browser’s Developer Tools (
Cmd+Option+Ion macOS orF12on Windows/Linux). - Go to the Network tab and click the Clear button.
- Paste a sample payload and click the tool’s action button.
- Observe the log.
A genuinely private client-side tool will produce zero outbound requests during interaction. If you see POST requests, newly opened WebSockets, or background navigator.sendBeacon pings firing after you paste your data, the tool is not operating purely locally.
2. The Offline Test
- In DevTools, locate the network throttling dropdown in the Network tab.
- Select Offline (or toggle off your machine’s Wi-Fi).
- Attempt to run the tool.
If the utility fails or displays a network error, it relies on a server-side processing pipeline. If it keeps working, the computation is running entirely inside your browser.
3. Content Security Policy (CSP) Verification
A site can also restrict its own networking with a Content Security Policy, a response header the browser enforces.
When examining the response headers for the site’s initial HTML document, check the Content-Security-Policy header:
Content-Security-Policy: default-src 'self'; connect-src 'none'; object-src 'none';The key directive is connect-src. Unlike a privacy policy, it’s enforced by the browser itself, and Chromium, WebKit, and Gecko all support it. Set to 'none', it blocks every connection a script on the page tries to open with fetch(), XMLHttpRequest, WebSocket, EventSource, or navigator.sendBeacon(). A policy that lists a few named servers instead is still useful, as long as you recognize them.
CSP has limits. It doesn’t stop a script from navigating the whole tab to another URL, and it has no effect on browser extensions, which can read any page. Treat it as a second layer behind the Network tab and offline checks, not a replacement for them.
The Architecture Behind worktools.dev
I wanted worktools.dev to be a site you could paste production data into without a second thought, and a few decisions make that possible.
The site is built with Astro into static files. There’s no backend runtime, no edge function that receives your input, and no database. The Strapi converter and the text generators run in memory with built-in browser APIs like JSON.parse() and FileReader, so nothing is stored and the output is gone when you close the tab. Every page is served with a Content Security Policy that limits which servers scripts can contact; the Security page shows the current policy and what it does and doesn’t cover.
Just as important is what I left out: no accounts, no saved snippet URLs, and no third-party error tracking or session replay scripts that could capture what you type.
Evaluating Tools for Your Engineering Team
As organizations grow, security teams frequently respond to credential leaks by blocking domains at the corporate DNS or firewall level. But developers under deadline pressure will always find workarounds, often moving to other unvetted utility sites.
The better solution is to establish clear internal criteria for approved utilities:
- Verify offline capability: Does the utility function with Wi-Fi disabled?
- Inspect network egress: Does the tool show zero post-interaction network requests?
- Verify CSP headers: Does the site send a
connect-srcpolicy that blocks connections or limits them to servers you recognize? - Avoid permanent sharing links: Does the tool lack server-side snippet storage?
A tool that passes all four is one your team can use during an incident without a second thought.