How to verify an online tool doesn't upload your data

The short answer. Any browser-based tool that claims "your data never leaves your browser" can be verified in 30 seconds with built-in browser tools. Open Chrome DevTools (F12), switch to the Network tab, tick Preserve log, reload the page, then run the tool with your data. If the Network panel shows zero outbound requests carrying that data, the claim is true. If you see a POST request with your data in the body, the claim is false. Same procedure works in Firefox, Safari, and Brave with minor UI differences. The next section explains why this matters and how to read what you see.

Why "we don't upload" is easy to claim and hard to verify

Every privacy-aware text tool says the same thing on its homepage: "your text never leaves your browser". Some are telling the truth. Some are not. The two look identical until you check.

A tool that processes data locally needs zero outbound requests after the page loads — the input goes through JavaScript in your tab and comes back as the result. A tool that processes data on a server needs an HTTP request carrying your data, even if the URL and timing are designed to look unobtrusive. The difference shows up in the Network panel; the marketing copy does not.

Most users don't check. The few who do can verify for themselves in under a minute — and the rest benefit from the public ability to verify, because tools that lie get caught eventually.

How to verify in Chrome / Edge / Brave

All three browsers share the same DevTools (built on Chromium). The shortcuts and UI are identical.

1. Open DevTools. Press F12, or Ctrl+Shift+I on Windows / Linux, or Cmd+Opt+I on macOS. A panel docks to one side of the window.
2. Switch to the Network tab. Click Network in the DevTools menu bar. The panel will be empty at first — DevTools only records activity while it's open.
3. Tick Preserve log. The checkbox is in the toolbar at the top of the Network panel. This keeps the log across page reloads, so you can see what happens before and after running the tool.
4. Tick Disable cache. Next to Preserve log. Forces the browser to fetch fresh resources instead of using cached ones, so you see real requests rather than ghosts from earlier visits.
5. Reload the page. Ctrl+R or Cmd+R. The Network panel fills with the page's resources — HTML, CSS, JavaScript, fonts, images. These are normal: the browser is downloading the tool itself.
6. Note the request count at the bottom of the panel. Something like "12 requests / 50 KB transferred". Remember this number.
7. Run the tool with your test data. Paste something, click the button, do whatever the tool does. Then look at the Network panel again.
8. Check whether the request count went up. If it stayed the same, no new requests were made — the tool ran entirely in your tab. Verified, claim is true. If new requests appeared, click each one and inspect them.

For each new request, the Headers tab shows the URL and method, the Payload tab shows what was sent (if it was a POST or PUT). If you see your test data in the payload, the tool sent it to a server. If the new requests are clearly unrelated (an analytics ping that doesn't include your input, a font file downloaded late), the privacy claim might still be true — but you've earned the right to be skeptical.

Filtering noise out

The full Network panel includes everything: the page HTML, every script, every image, every font. For verifying "no upload of my data", only certain request types matter.

Click the Fetch/XHR filter button in the toolbar. The panel now shows only the API-style requests — XMLHttpRequest, fetch(), and the like. This is where data uploads happen. If the Fetch/XHR list is empty after running the tool, your data didn't travel.

Hold Ctrl (or Cmd on macOS) while clicking other filter buttons to add them. Doc + Fetch/XHR gives you both top-level page loads and API calls — useful for tools that submit via form post rather than fetch.

In Firefox

Same idea, slightly different UI.

1. Press F12 or Ctrl+Shift+E (Windows / Linux) / Cmd+Opt+E (macOS) — the second shortcut opens DevTools straight to the Network tab.
2. Tick Persist logs (Firefox's equivalent of Preserve log) and Disable cache.
3. Reload, run the tool, watch the request list.

Firefox's request type filters work the same as Chrome's. Click XHR to narrow to API calls.

In Safari

Safari hides DevTools by default. Enable it once:

1. Safari → Settings → Advanced → Show features for web developers (Sonoma 14.4+). On older macOS versions the option is named Show Develop menu in menu bar. Close Settings.
2. Right-click the page, Inspect Element, or use Cmd+Opt+I.
3. Switch to the Network tab. Click the XHR filter pill near the top.
4. Tick Preserve Log. Reload. Run the tool. Inspect.

Safari's Network panel is laid out slightly differently from Chrome but the verification logic is identical — look for new XHR / Fetch requests that contain your data.

Common false positives

Sometimes the Network panel shows a new request after you run the tool, but the request isn't actually carrying your data. Three legitimate reasons:

• Analytics or page-view scripts. A tool that uses Google Analytics or Plausible will send a request to the analytics endpoint — but with metadata only (page URL, browser, timezone), not your input. Click the request, check the Payload tab. If your test text isn't there, the tool didn't upload it.
• Browser extensions. Ad blockers, password managers, accessibility tools all make their own requests. These show up in the Network panel but didn't come from the tool. Chrome 117+ has a Hide extension URLs checkbox under More filters in the Network panel's filter bar — tick it for a cleaner view.
• Service workers. Some PWAs cache resources via a service worker, which can produce phantom requests. The Initiator column shows what triggered each request; if it says service-worker, the request came from caching logic, not your action.

When in doubt, click the suspect request and look at the Payload / Request body. Your data either appears there or it doesn't. The check is binary.

For the paranoid: blocking all outbound requests

To convince yourself a tool works entirely offline, you can prove it by blocking the network entirely while it runs. Chrome DevTools has a request-blocking feature:

1. Open DevTools, Network panel.
2. Open the request-blocking drawer: top-right three-dot menu → More tools → Network request blocking. (Faster: press Ctrl+Shift+P on Windows / Linux or Cmd+Shift+P on macOS, type "block", pick Show Request Blocking.)
3. Add a wildcard * pattern to block everything.
4. Reload the page (it should still work if everything was already cached).
5. Run the tool with your data. If it works with all outbound requests blocked, the tool genuinely runs offline.

For an even stronger test, turn off WiFi / disconnect Ethernet, then run the tool. If it still works on a disconnected machine, no data is going anywhere — verified by the strongest test possible.

Frequently asked questions

What if the tool's HTML / JS already loaded before I opened DevTools?

DevTools only logs requests that happen while it's open. If you open DevTools after the page loaded, the page-load requests will be missing — that's fine, you're checking what happens after you interact with the tool. The exception is if the tool lazy-loads code on user action; reload the page with DevTools already open to catch everything.

Can a tool detect that DevTools is open and behave differently?

Technically possible, practically rare. Detecting DevTools requires fingerprinting tricks that are obvious in the JavaScript source. If you're verifying a tool that's small enough to inspect (a few hundred KB), open the Sources tab in DevTools and grep the JS for devtools, debugger, or window-size-based detection. The joinlines tools are a few hundred bytes of JavaScript per tool — verifiable in a single read.

What about WebSocket connections?

WebSockets show up in the Network panel under the WS filter. The verification logic is the same: if you don't see a WebSocket connection in the WS list, no streaming upload is happening. If you see one, click it and check the Messages tab for outbound frames containing your data.

Why don't more privacy-tool review sites do this check?

Because most reviewers test usability and UI, not network behaviour. Privacy claims are accepted at face value unless someone specifically calls them out. The 30-second check is something users can do for themselves — and once you've done it for one tool, you can do it for any. We hope more tools welcome the scrutiny; we think the ones that don't are telling you something.

Is "DevTools verification" useful when I'm not technical?

Yes, with one warning: knowing what a Network panel should look like takes practice. For a non-technical first check, the request count test is enough — reload the page, note the number, run the tool, see if it goes up. If it doesn't, you're done. If it does, ask someone technical to inspect the new requests before deciding the tool is dishonest.

How do I verify the joinlines tools specifically?

Open any tool page (the line break remover, the list alphabetizer, any of the eight). Open DevTools, Network tab, Preserve log on. Reload. Run the tool with any text. After the initial page load, the request count should not increase by any Fetch/XHR row carrying your input. We re-check this whenever shipping changes that touch tool code — the whole point of the "no upload" claim is to make it verifiable from your end.

— the joinlines team, 2026-05-23