Skip to content
d.devtul.fun
中文
Privacy · 2026-09-10

Why these tools belong in your browser

Picture a routine moment: a production endpoint returns something strange and you need to see what that JSON actually looks like. The quickest path is usually to search for an "online JSON formatter" and paste it in.

The problem is what is inside that paste. It may well contain an access token, a customer's phone number, an internal hostname, a database connection string, or an entire configuration that has not shipped yet.

The only question that matters: does the data leave your device?

From your side of the screen the two sites look identical. Underneath they can behave completely differently:

  • Client-side processing. The data goes into page memory, JavaScript handles it, the result is rendered. The network panel shows the page's own requests and nothing else.
  • Server-side processing. The data is POSTed to somebody's backend and comes back. Access logs, request-body logs, and whatever CDN or WAF sits in front of it may all retain a complete copy.

The danger in the second case is not that the operator is necessarily malicious. It is that you have no way to verify what they did, and once the data has left your device you cannot take it back.

How to tell which kind of site you are on

You do not need to read the source. Three quick checks:

  1. Open the developer tools and switch to the network panel. Type something into the tool and watch for new requests. If nothing fires as the input changes, the work is happening locally.
  2. Try it with the network off. Disconnect after the page loads. If the tool still works, it cannot be depending on a server.
  3. Read the claims. Sites that say "your data never leaves the browser" and explain the mechanism tend to be more trustworthy. Sites that promise "military-grade security" without saying how deserve more scepticism, not less.

What local processing costs you

It is not free. Some tasks genuinely need a server: calling third-party APIs, heavy computation, collaborative editing with shared state. Browser memory and CPU are finite, and there is no place to sync or persist anything.

But for "format this JSON", "compute a hash" or "decode this JWT", the trade-off is barely a trade-off:

  • Lower latency — no round trip to wait for
  • No privacy cost — the data never left memory in the first place
  • Works offline — load the page once and it keeps working on a plane
  • No running cost — static hosting needs no advertising and no data sales to pay for it

How this site does it

All twelve tools on devtul.fun are implemented purely on the front end. Once a page has loaded you can pull the network cable out — they keep working, because they never needed it.

Verifying that takes about ten seconds: open any tool page, press F12, switch to the network panel, and paste a large block of text in. The request list will not move.

There is nothing clever about the architecture. It is just a matter of leaving the things that should stay local, local.

Keep reading