Notes
Why most browser tools never need the network
Hashing, formatting, and encoding can stay on the page. DNS, certificates, and "what is my IP" cannot. This note separates the two data paths and shows how to check that an input was not sent.
By Brook/Updated 2026-10-09/12 min read
Which code "runs in the browser" refers to
JavaScript on the page runs on your machine. JSON.parse, TextEncoder, Web Crypto, Canvas, and DOMParser keep their inputs and outputs in that page's memory. The functions themselves do not open a connection. A local tool is one whose result comes only from those calls, and whose pasted input never becomes a request body.
That is not the same claim as "opening the site causes no requests". HTML, scripts, and styles still have to be downloaded or the page cannot render. What gets downloaded is the program, not your input. Draw the line at "is the input part of a request?", not at "did this tab use the network at all?".
A local tool stops at these three layers
- 01OutputThe result stays on the pageYou can copy it. The site does not receive the text because you clicked format.
- 02ComputeBrowser APIsParsing, Web Crypto, Canvas, DOMParser. They do not start an application request.
- 03InputWhat you pastedIt enters this page's memory. A reload drops it, unless you turned on the local draft.
If you turn drafts on, they are written to this browser's localStorage. The key stays on the device. There is no account to sync it to. A share link is a different path: when you choose to share, the input is placed in the URL hash. A hash is not sent to the server with the HTTP request, but anyone you give the full URL to can open the same input. If you do not share, that hash is not created.
Four questions have to leave the machine
A browser does not let an arbitrary page run DNS lookups against arbitrary hosts, complete a TCP handshake, or read "what public address reached this site". Those facts are outside the page's authority. Answering them needs a server that is already on the network to ask, then return the result. The domain, the certificate hostname, or the connection itself does reach that server.
Stays local
The input is the data to transform.
- Parse and print JSON, YAML, XML
- Hash, HMAC, AES
- Base64, URL encoding, JWT decode
- Regex, diff, timestamps, images
Must leave
The question is about the network outside the browser.
- DNS answers
- A TLS certificate chain
- Response headers for a URL
- The public IP of this connection
Those four pages should not pretend to be local-only. The form needs to say the query goes through a server. They ask about a domain, a hostname, or the connection, not about a document you pasted into some other tool. Do not send a private key or a customer JSON payload through a network check "while you are here".
What measurement and ad scripts can see
Measurement and ad scripts used by the site can see page-level facts: which URL you opened, a rough device and region, and cookies they set themselves. They do not receive the string inside a tool input, unless that string was placed in the URL. Local computation does not turn the input into a query parameter. Check that claim in the request list, not by trusting a sentence.
Ad scripts pay for the site. They do not take part in formatting or decoding. After you block third-party scripts, the tool buttons should still work, because the math does not depend on them. If a tool suddenly cannot run with those scripts blocked, it is wrongly depending on a remote request, and that is a defect.
How to confirm an input was not sent
Open the browser developer tools, switch to the network panel, and preserve the log. Paste a distinctive string, such as a run of random characters, into a local tool, then format or compute. Search the request list for that string. During a local tool there should be no request that contains it. Script downloads, fonts, and measurement requests may still appear. Their bodies do not contain your input.
- Clear the network list before you paste, so page-load requests are not mixed in.
- Search for your input, not for the name of the tool.
- The share button changes the address bar only after you click it. That step is you putting the input into the hash.
- DNS, certificates, response headers, and IP are the opposite: they are supposed to send a query, and the page should say so.
This site writes that boundary into the tool pages and the privacy notes, and the steps above are enough to recheck it. The notes explain the mechanism. The buttons on a tool page do the work. If the two disagree, the request list wins.
Tools mentioned here
Keep reading
- How JSON parsing works, from characters to a valueFormat, minify, and tree view look like three buttons. Underneath they share one pipeline: split the text into tokens, then fold those tokens into a value. This note walks that path and shows where line numbers come from.
- What UTF-8 actually encodesCharacter counts, code points, and bytes are three different rulers. This note walks one code point through UTF-8 and explains why URL encoding and JSON escapes look nothing like each other.
- The three parts of a JWT, and what verification checksDecoding the header and payload does not mean the token can be trusted. This note separates Base64URL, the signature, and claim checks, and explains why the algorithm and the key have to be chosen together.