Developer tools · Text comparison
How to Verify a Browser Diff Tool Never Uploads Your Text: DevTools Guide
· How it works
text-diff privacy browser-processing
A step-by-step walkthrough of using the browser's network panel to confirm that a comparison runs locally, plus what a strict Content Security Policy tells you about the page.
'Runs in your browser' is a claim you can test — states the problem: privacy pages are promises, network requests are facts
“Runs in your browser” should be tested at the narrowest useful boundary. For Text diff, the repository shows editor values passed directly to `diffLines`, rows rendered into DOM nodes, and optional output handed to a local download helper. No comparison API sits in that chain.
Static source is one form of evidence, not a guarantee about every deployed page component. Pair it with a runtime observation using harmless marker text. That combination supports a precise claim about the action you performed without pretending to audit browser extensions, operating-system clipboards or future releases.
Opening the network panel before you paste — shows how to open DevTools, clear the request list and keep it recording
Open developer tools before entering sensitive material. Select Network, clear earlier page-load requests, preserve the log only if needed, and keep recording. Use a distinctive but non-secret marker on each side so you can search request URLs, headers and bodies without exposing real content.
Load-time assets are not evidence that comparison text was transmitted. The useful observation is whether clicking Compare, toggling options, swapping sides or downloading creates a request containing the marker. Record the page version and browser so another reviewer understands the scope of the check.
Reading the requests during a comparison — explains what should appear (nothing new) and what would be a red flag: POST requests, beacons, third-party hosts
During Compare, `diff.js` receives two strings and options. It normalizes line endings, derives line keys, builds a bounded typed-array table and returns rows. The UI maps those rows to elements using text content. None of those functions calls fetch, XHR, WebSocket or a beacon.
Download follows another local path: `toUnifiedText` creates a string with headers and prefixed rows, then `downloadText` produces the browser download. Verify that helper when making a complete claim about saving. Reading only the algorithm would leave the final action outside the evidence chain.
What a Content Security Policy header reveals — describes how ToolAcre's strict CSP forbids external scripts, fonts and tags, and how to read the header in the response view
The outline asked for a strict Content Security Policy conclusion, but CSP is a response property and deployment evidence is not contained in these comparison files. Inspect the actual document response in Network when CSP belongs to your threat model, and report the directive exactly as observed.
A restrictive policy can reduce some classes of external loading, yet it does not replace tracing the feature. Conversely, the absence of a desired directive would not prove that Compare posts text. Keep policy inspection and data-flow observation as distinct findings rather than letting one stand in for the other.
CSP evidence belongs to the deployed response, not the text-diff source files reviewed here
For a worked check, enter `left-marker-7319` and `right-marker-4826`, clear Network, then click Compare with Ignore case off and on. Search new request details for both markers. The expected repository path performs DOM work only, so the action itself should not require a text-processing request.
If a request appears, identify its initiator and payload before concluding that the diff sent content. An extension or unrelated page script can create traffic at the same moment. The marker test narrows the question: whether those distinctive values entered that request, not whether the browser made any request at all.
Why no account and no storage is part of the same check — covers inspecting browser storage to confirm nothing persists between visits
The UI stores `lastDiff` in a local variable so Download patch can use the latest result. Clear empties both editors, clears rendered output and sets that variable to null. The reviewed path contains no localStorage, IndexedDB or account call for comparison history.
That source finding is narrower than “nothing persists anywhere.” Browser form restoration, extensions and copied text have separate behavior. Inspect Storage for the current origin and reload with harmless markers if persistence matters. State exactly what you observed rather than elevating one code search into a universal privacy promise.
The tool exposes no persistence call; inspect current browser storage separately before broad claims
This review covers ToolAcre’s Text diff modules and the local download helper used by its UI. It does not certify every script loaded by a deployment, network middleware outside the repository, injected extensions or clipboard managers. Those components require their own evidence.
The safest operational habit remains minimization: paste only the fields required for comparison, use redacted fixtures for verification, and keep highly regulated material in an approved environment. A browser-side implementation removes one processing server from the path; it does not remove every surrounding system.
Extensions and the deployed page remain outside the static comparison-path proof
A trustworthy no-upload statement names its scope and date. Source review proves the comparison call graph lacks a network operation; a clean marker test proves what happened in one runtime session. Together they are stronger than a privacy slogan and easier to repeat after a release.
Run the check before relying on the tool for confidential work, then compare only material your browser environment is allowed to hold. Evidence should travel with the conclusion: source paths, observed requests and any unreviewed layers, not an absolute assurance unsupported by the complete path.