Does This Online Tool Upload Your Input?

By ZIV LABS · Written and checked October 20, 2026 · Chrome (observation), Node.js v24.7.0 and curl (URL demo)

"Runs in your browser" is a claim you can check, and also a claim with limits. Many online developer tools say they process your input locally. This note shows how to test that claim with your browser's developer tools, what we saw when we tested our own tool, why a clean result is evidence rather than proof, and why it matters whether your input ends up in a URL. The commands below were run on Node.js v24.7.0 and curl; the browser observation was made in Chrome on October 20, 2026.

What the claim does and does not mean

"Runs in your browser" means the formatting, decoding, or conversion is done by JavaScript on your device, so the text you paste does not need to be sent to a server to produce a result. It does not mean the page makes no network requests at all. The page itself, its scripts, and its styles come from a server, and a site may also load analytics or ads. The question to ask is narrower: does my input leave the browser?

How to check, step by step

Open the tool's page and wait for it to finish loading. Use harmless test data, never a real token or secret, until you have checked.
Open your browser's developer tools and go to the Network panel. In Chrome, the Preserve log checkbox keeps requests across page loads, Clear empties the list, and the Fetch/XHR filter shows the requests scripts make.
Click Clear, then paste your test input and run the tool.
Look at the list. A new request after you pressed the button is worth opening: check its method (a POST with a body is the usual way to send data), its URL, and its payload.
Optional: set Network throttling to Offline after the page has loaded and run the tool again. If it still works, that action did not need a server.

What we saw on Small Tools

We ran this check on the JSON Formatter page of Small Tools, a ZIV LABS product, on October 20, 2026 in Chrome, in one session, with the tool's own sample input ({"name":"Ada","active":true,"skills":["design","logic"]}).

While the page loaded, the browser requested the page's own HTML, JavaScript, and CSS, route data for pages linked from the header, a script from Cloudflare's Web Analytics (static.cloudflareinsights.com), and made a POST to /cdn-cgi/rum. The Cloudflare script is analytics; the Small Tools privacy policy mentions it. We did not inspect the payload of that request.
After we cleared the list, loaded the sample, and pressed Format, the formatted result appeared and no new request was made when the button was pressed. The only requests between clearing the list and pressing the button were two background loads of route data for linked pages, which are not related to the input.

This is one observation, not a guarantee. We did not test other Small Tools pages, large inputs, error cases, other browsers, or the offline mode.

Why a clean result is evidence, not proof

You tested one session. Code can behave differently for other inputs, error paths, or later versions. A site can change its scripts at any time, so the result applies to the version you loaded.
The Network panel shows what the page sends, not what happens next. It cannot show what a browser extension reads from the page, or what you later paste into a chat or an issue.
Loaded scripts can read the page. An analytics or ad script that is loaded on a tool page runs in the same page. A clean Network panel during your test is evidence that it did not send your input then; it is not a statement about all scripts and all times.
Local processing is not anonymity. The server that delivers the page still sees ordinary request data such as your IP address and the page you requested.

Where your input lives in the URL matters

Some tools put your input into the address so you can share a link. Whether that part of the URL reaches the server depends on where it sits. The part after ? (the query) is part of the request. The part after # (the fragment) is handled by the client before the request is made (RFC 3986 §3.5). Here is a server that prints what it receives, and two requests:

import { createServer } from "node:http";

// Logs exactly what the server receives for each request.
createServer((req, res) => {
  console.log(`${req.method} ${req.url}`);
  res.end("ok");
}).listen(9000, () => console.log("listening on 9000"));

$ node server.mjs &
listening on 9000
$ curl -s 'http://localhost:9000/format?input=secret-in-query#secret-in-fragment' > /dev/null
$ curl -s 'http://localhost:9000/format#only-fragment' > /dev/null

The server's log shows:

GET /format?input=secret-in-query
GET /format

The query reached the server and the fragment did not. We checked this with curl; we did not test it in browsers, though they follow the same URL rule. A tool that stores your input in the query string sends it to the server on every load, where it can appear in server and analytics logs. After you run a tool, look at the address bar: if your input appears in it, find out whether it is after a ? or after a #.

What site owners can do

A Content-Security-Policy header with a connect-src directive limits where a page's scripts can send requests with fetch, XMLHttpRequest, WebSocket, EventSource, and sendBeacon. A tool page that sets it to its own origin makes its own claim much easier to trust. We did not test any such policy for this note. When we looked at the response headers of the Small Tools JSON Formatter page on October 20, 2026, they included x-content-type-options and referrer-policy but no Content-Security-Policy, so for now the Network panel is the way to check.

Checklist

Test with harmless data first, then watch the Network panel while you press the button.
Look for new requests after the button, especially POST requests with a body.
Check whether your input appears in the address bar, and whether it is after ? or #.
Treat a clean result as evidence for that page, that input, and that moment.
For real secrets (tokens, keys, customer data), prefer redacted or test values even when a tool says it runs locally.

What we did not verify

We observed one tool page in one browser session. We did not inspect the payload of the Cloudflare performance request, test the offline mode, test other browsers, other tools, large inputs, or error paths, or test a Content-Security-Policy. The curl demonstration covers how the request line is built, not how every browser or proxy handles URLs.

References

Related tools

JSON Formatter — The page we observed. It states that it runs in the browser; the observation above was made on this page.

Small Tools is built and operated by ZIV LABS. These links go to tools.ziv-labs.com.

Related notes

JWT verification mistakes — Four tokens a flawed JWT verifier accepts and a strict one rejects: alg none, RS256-to-HS256 confusion, and unchecked claims, reproduced with runnable Node.js code.

Does this online tool upload your input?