When we say "client-side only," we mean it architecturally, not just as a policy. The formatting and conversion logic runs in your browser. Our servers never receive your input data — not even in an encrypted form.
The Problem With Server-Side Formatters
Most online developer tools work the same way: you paste your data, it gets sent to a server, the server processes it, and the result is sent back. It's simple to build and works fine for public data.
But developers routinely paste sensitive information into formatting tools without thinking twice — API keys embedded in JSON configs, database connection strings in YAML files, personally identifiable information in CSV exports, JWT tokens being debugged. The assumption is that the tool is just a utility, not a data sink.
That assumption is wrong. Every server-side tool represents a potential logging point, a breach surface, and a compliance risk. If you're operating under SOC 2, HIPAA, GDPR, or just your company's internal security policies, pasting sensitive data into external servers is a problem.
How We Built It Differently
OpenFormatter's core formatting engine runs entirely via JavaScript and WebAssembly in your browser. When you paste JSON and click "Format," the computation happens on your machine. The result is computed locally and displayed locally. Nothing traverses the network.
This isn't just a feature flag — it's an architectural constraint we imposed from day one. There is no server-side formatting endpoint. There's nothing to disable, no configuration to accidentally enable. The data simply never leaves your browser.
{label}
{desc}
{label}
{desc}
{label}
{desc}
{label}
{desc}
What This Means for Your Workflow
In practice, client-side processing means you can safely use OpenFormatter for:
You can verify this yourself: open your browser's network inspector, paste some data, and click Format. You'll see zero outbound requests containing your input. The proof is in the network tab.
The Trade-offs
Client-side processing has constraints. Very large files (hundreds of MB) can be slow or cause browser memory pressure. Complex transformations that would benefit from server-side libraries are harder to implement in a browser context. And WebAssembly compilation adds a small initial load time.
We think those trade-offs are worth it. The alternative — asking users to trust that their sensitive data is handled safely on an external server — isn't a trade-off we're willing to make on your behalf.
See It for Yourself
Open the network inspector, paste your data, and watch — zero outbound requests.