My company's security policy prohibits uploading source code to any external service. I found out after nearly pasting a config file containing a staging database connection string into a popular online JSON formatter. It formats the JSON server-side. The connection string would have been in their request logs. The tool looks like a simple text box. The risk is not obvious until you think about what happens when you click “Format”.
Format JSON locally — your code never leaves the browser.
Client-side JSON formatter, YAML converter, regex tester. No server. No account.
Open JSON Formatter →What Developers Actually Paste Into Online Tools
Developers use online formatters and converters constantly. Here is what they commonly paste — and why each one carries risk:
| What They Paste | Common Sensitive Content | Risk |
|---|---|---|
| JSON config files | API keys, database URLs, service credentials | Critical |
| YAML Kubernetes configs | Docker registry credentials, cluster secrets | Critical |
| API response payloads | User PII, auth tokens, internal IDs | High |
| SQL query results | Customer data, employee records | High |
| Log files for debugging | IP addresses, user sessions, error traces with paths | Medium |
Why Most Online Formatters Are Server-Side
Many popular online JSON, YAML, and code formatters were built before WebAssembly existed or before browser-based alternatives were common. The architecture is a simple form that POSTs your input to a server endpoint, formats it server-side, and returns the result.
This architecture means your input travels to a server over HTTP. It appears in: server application logs, web server access logs, monitoring/analytics pipelines, error tracking systems (Sentry, Datadog), and potentially CDN caches if the response is cached.
# Check if a formatter is server-side:
# Open DevTools > Network tab > click "Format" on a test input
# Server-side (bad for sensitive data):
# POST /api/format HTTP/1.1
# Content-Type: application/json
# {"input": "{"apiKey": "sk-1234567890abcdef"}"}
# ↑ Your API key just went to their server
# Client-side (safe):
# No network requests during formatting
# The format operation happens in the browser's JavaScript engine
# JSON.stringify(JSON.parse(input), null, 2) — no server involvedWhat Security Policies Actually Cover
Most corporate non-disclosure agreements prohibit sharing “confidential information” with third parties. Most IT security policies prohibit using unapproved software to process company data.
Using an online formatter for a config file containing internal API endpoints, service names, or credentials is almost certainly covered by both. The fact that the tool is a text box rather than a file upload does not change the data classification of what you pasted.
Local-First Alternatives for Every Common Dev Task
| Task | Local Alternative |
|---|---|
| Format JSON | VS Code (built-in), FileMint JSON Formatter (client-side), jq . in terminal |
| Validate YAML | yamllint (CLI), FileMint YAML to JSON (client-side) |
| Test regex | FileMint Regex Tester (client-side), grep locally |
| Base64 encode/decode | echo "text" | base64 (terminal), FileMint (client-side) |
| Hash a file | sha256sum file.txt (terminal), FileMint (client-side) |
| Convert CSV to JSON | csvkit (Python), FileMint (client-side) |
The terminal alternatives work without any browser tool. For situations where you want a visual interface without the server risk, client-side browser tools are the right choice. For the full context of why this matters beyond developer workflows, our file upload risk guide covers the GDPR and Terms of Service angles in detail.
Local dev tools — JSON, YAML, regex, Base64.
Client-side tools for developers. Your code stays in the browser.
View All Local Tools →