Private, client-side text comparison

The hidden risk of online diff tools

Most online text comparison and diff tools operate as cloud services. When you paste two blocks of text or upload files, your browser packages the contents into an HTTP POST request and sends them to a remote web server. That server runs the diff algorithm in its own process, stores temporary files, records incoming payloads in application logs, and sends an HTML or JSON response back to your screen.

For public prose or open-source snippets, that round trip is harmless. For almost anything else, it is an avoidable security hazard:

• Internal source code: Exposing proprietary algorithms, infrastructure configurations, database schemas, or unreleased features to third-party servers.
• Credentials and secrets: Accidentally pasting .env files, API keys, database connection strings, JWT tokens, or private certificates into an external log stream.
• Legal and financial documents: Pasting merger terms, non-disclosure agreements (NDAs), contract negotiations, or patent applications into third-party storage.
• Personally identifiable information (PII): Breaching regulations like GDPR, HIPAA, or CCPA by uploading patient records, customer lists, or internal payroll files to an unvetted endpoint.

Once text is sent to a remote host, you cannot verify how long it is retained, whether it is backed up, who has root access to the host, or whether it feeds an automated telemetry pipeline or model training dataset.

How client-side diffing works

This tool does not have a server-side diff engine. When you visit this site, your browser downloads static HTML, CSS, JavaScript, and pre-compiled WebAssembly modules. Once those assets load, every calculation takes place locally on your machine.

The architecture relies on three browser-native primitives:

1. Web Workers: The text comparison engine runs inside a dedicated browser background thread (Worker). Heavy computations — like Myers diffing, semantic block pairing, and Levenshtein token alignment — execute without freezing your browser interface, but they remain strictly confined to your device's memory.
2. WebAssembly (WASM): Syntax parsing for tree-sitter grammars (JavaScript, TypeScript, Python, JSON, HTML, CSS) runs as compiled WebAssembly binaries executed by your browser's V8 or JavaScriptCore engine.
3. Local File APIs: When you drag and drop a .docx, .pdf, .csv, or .txt file onto either panel, the document is read via FileReader and unpacked with browser-based libraries. The file never leaves your operating system's memory space.

Because no server endpoint exists to receive comparison inputs, your text cannot be intercepted in transit, logged on a cloud server, or retained in an external database.

How to verify that nothing leaves your browser

You do not have to take any website's privacy claims on faith. You can verify whether an online tool sends your data over the wire using your browser's built-in developer tools:

1. Open Developer Tools in your browser (press F12, or right-click anywhere and select Inspect).
2. Click on the Network tab.
3. Check the Fetch/XHR filter so you only see background API requests.
4. Paste confidential text into both panels, or drop two large documents into the comparison view.
5. Observe the Network log while the comparison runs and updates.

You will see zero outgoing HTTP requests containing your text. The status bar at the bottom will report the diff stats and token counts immediately, generated entirely by your local CPU.

Local storage, sharing, and offline usage

Because there is no remote database, data persistence is under your direct control:

• Saved comparisons: If you choose to save a comparison for later review, it is written to your browser's local storage (IndexedDB or localStorage) on that specific device. It never syncs to a cloud profile. If you clear your browser cookies and site data, the saved items disappear.
• Shareable links: If you generate a share link, the text is compressed and encoded into the URL's hash fragment (the portion after #). Web browsers never transmit the hash fragment to HTTP servers during page requests. However, anyone you share that exact URL with can decode and read the text, so avoid pasting generated share links into public channels or unencrypted chats.
• Offline availability: Because all engines, parsers, and styling assets are cached locally by the browser, you can disconnect from Wi-Fi or turn on Airplane Mode and the comparison tool will continue working with zero degradation.

When to use a local desktop diff vs a client-side web diff

For day-to-day code review and sensitive document audits, an in-browser client-side tool provides the convenience of an instant zero-install interface without the security liabilities of traditional cloud web apps.

The few occasions where a dedicated local command-line or desktop application (such as git diff, diff, or GUI tools like Meld) is preferable:

• Massive files: Browser memory limits typically throttle single-tab performance when comparing files exceeding 100,000 lines or 50 megabytes.
• Binary files: Comparing compiled executables, raw images, or audio waveforms requires specialized byte-level hex differs.
• Multi-file folder diffs: Comparing entire directory hierarchies across branches is best handled by your version control system directly in the terminal.

For comparing text snippets, configuration drafts, database dumps, contracts, or code refactors with total privacy, client-side browser comparison gives you complete confidentiality with zero footprint.