Why Your Diff Tool Shouldn't See Your Code

Here's something most developers don't think about: every time you paste code into an online diff tool, that content hits a server somewhere.

Config files. API keys. Internal service names. Database connection strings. Infrastructure YAML. It all gets sent to a third party, logged, and potentially retained — and you agreed to it somewhere in a terms of service you didn't read.

For most diffs that's fine. For the ones that matter, it's not.

The Problem With Server-Side Diff Tools

The popular online diff tools work like this:

1. You paste your content


2. It's sent to their server


3. The server computes the diff


4. The result is returned to your browser

That round-trip to a server is unnecessary. Your browser is perfectly capable of computing a diff locally — the same Myers diff algorithm that Git uses runs fine in JavaScript. But server-side processing is the default architecture, so that's what most tools use.

The risk is real: developers routinely paste things like:

• Terraform state files containing AWS credentials


• 
  .env files with API keys and database URLs


• Kubernetes secrets (yes, even base64-encoded ones)


• Internal API responses with customer data


• CI/CD configs with tokens and webhook secrets

A single careless paste into the wrong tool and that content is sitting on someone else's server.

How Client-Side Diffing Works

Online Diff runs the entire diff in your browser using JavaScript. There is no server involved in the comparison — the content never leaves your machine.

The architecture is simple:

Your browser

  ├── Left panel (your original text)

  ├── Right panel (your modified text)

  └── Diff engine (Myers algorithm, runs locally)

       └── Output rendered in your browser

Nothing is transmitted. Nothing is stored. If you close the tab, it's gone.

This works for text, JSON, YAML, CSV, XML, and code — all computed locally, all syntax-highlighted in-browser.

PII Detection Before You Share

Client-side processing is table stakes. The more interesting problem is sharing.

Sometimes you want to send a diff to a teammate — a link they can click and see exactly what you're looking at. That's where things get complicated, because the sharing URL has to encode the content somehow.

Before generating a share link, Online Diff scans your content for six categories of sensitive data:

If anything is found, you get three options before the link is generated:

1. Redact — Sensitive values are replaced inline:

API_KEY=sk-abc123...  →  API_KEY=[REDACTED_TOKEN]

[email protected]      →  [REDACTED_EMAIL]

192.168.1.100         →  [REDACTED_IP]

The diff still shows the structural changes. You just can't see the actual values.

2. Encrypt — The entire content is encrypted with a password you choose before being encoded into the URL. The recipient needs the password to view it.

3. Share anyway — If you've reviewed the content and it's fine, skip the warning.

How the Encryption Actually Works

The encryption uses the browser's built-in Web Crypto API — no third-party crypto libraries, no server involvement.

When you choose to encrypt:

1. A random 16-byte salt is generated


2. Your password is run through PBKDF2 with 100,000 iterations and SHA-256 to derive a key


3. The content is encrypted with AES-GCM 256-bit using a random 12-byte IV


4. The result (salt + IV + ciphertext) is base64-encoded and embedded in the URL

The recipient opens the link, enters the password, and decryption happens entirely in their browser. The server never sees the password or the plaintext — it only ever serves the page HTML and JavaScript.

This means:

• The share URL is safe to send over Slack, email, or a PR comment


• Even if the URL is intercepted, the content is unreadable without the password


• Online Diff itself cannot decrypt it — there's nothing server-side to compromise

When This Actually Matters

Code reviews with sensitive configs

Reviewing a PR that touches .env.example, Terraform variables, or Kubernetes manifests? Paste both versions, get the diff, share an encrypted link in the PR comment. Your reviewer sees exactly what changed without you having to sanitise the content manually.

Sharing API response diffs

Debugging a production API that returns customer data? Diff two responses locally, redact the PII, share the structural diff with your team.

Cross-team infrastructure reviews

Infrastructure changes often touch files with internal hostnames, IPs, and service names that shouldn't leave the company. A client-side diff with an encrypted share link keeps that data internal even when collaborating across tools.

Compliance-sensitive environments

If you're working in a HIPAA, SOC 2, or PCI-DSS environment, "we pasted patient data into a random website" is not a conversation you want to have. Client-side processing means there's nothing to explain.

The Takeaway

The next time you reach for an online diff tool, it's worth asking: does this need to go to a server?

For most diffs, it doesn't. The computation is trivial for a modern browser. The only reason to send it to a server is if the tool was built that way by default — not because it needs to be.

If you're working with anything sensitive, Online Diff keeps it in your browser. The PII scanner and encrypted sharing are there for the cases where you need to collaborate without exposing the content.

Try it at online-diff.com — compare text, JSON, YAML, CSV, XML and code entirely in your browser.