DEV Community: Shivam

Why Your Diff Tool Shouldn't See Your Code

Shivam — Mon, 27 Apr 2026 15:24:18 +0000

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:

You paste your content
It's sent to their server
The server computes the diff
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:

Type	What it detects
API keys / tokens	Strings of 32+ alphanumeric characters
Email addresses	Standard email format
IP addresses	IPv4 addresses
Credit card numbers	16-digit card patterns
Phone numbers	US phone number formats
Social Security numbers	SSN format (XXX-XX-XXXX)

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]
user@company.com      →  [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:

A random 16-byte salt is generated
Your password is run through PBKDF2 with 100,000 iterations and SHA-256 to derive a key
The content is encrypted with AES-GCM 256-bit using a random 12-byte IV
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.

How to Compare package.json Files: A Node.js Developer's Guide

Shivam — Tue, 21 Apr 2026 14:28:44 +0000

You open a pull request to review a dependency update and the diff is a wall of text — 80 lines of package names and version numbers. Your teammate says "just bumped a few deps", but buried in there is a downgraded React version and two new packages nobody discussed.

Manually spotting that by eye is error-prone. A proper side-by-side diff would have caught it in seconds.

Here are four methods for comparing package.json files, when to use each, and a workflow that fits into real code reviews.

Why package.json Comparisons Go Wrong

The obvious ones are easy — a new package name sticks out. The dangerous ones are subtle:

A minor version bump (^18.2.0 → ^18.3.0) that pulls in a breaking change via a transitive dependency
A peerDependency conflict where two packages need different versions of the same library — causing silent runtime bugs that your test suite won't catch
A package silently downgraded during a lockfile resolution
A devDependency accidentally moved to dependencies, inflating your production bundle

None of these are obvious from a quick glance at a git diff. They need a proper side-by-side comparison.

Method 1: Git Diff (Fastest)

The go-to for a quick local check before pushing:

git diff main..feature-branch -- package.json

To include more context lines around each change:

git diff -U10 main..feature-branch -- package.json

Always diff the lockfile at the same time — version constraints in package.json can hide transitive changes that only show up in package-lock.json or yarn.lock:

git diff main..feature-branch -- package.json package-lock.json

Best for: Quick checks before pushing. Not great for large files or sharing with teammates — the raw terminal output is hard to read.

Method 2: GitHub Pull Request Diff

If the PR is already open on GitHub:

Go to the Files changed tab
Scroll to package.json
Click the split view icon (two columns) for side-by-side mode

GitHub highlights added lines in green and removed lines in red. For large files, use the File filter dropdown at the top to jump straight to package.json.

Best for: Reviewing a PR before merging. Doesn't help when you want to compare arbitrary branches or files not in an open PR.

Method 3: Online Diff Tools (Most Visual)

For a detailed, shareable comparison — especially useful for large dependency updates or monorepo audits — paste both package.json files into an online diff tool like Online Diff.

Here's what a typical comparison looks like:

// package.json on main branch
"dependencies": {
  "react": "^18.2.0",
  "axios": "^1.4.0",
  "lodash": "^4.17.21"
}

// package.json on feature branch
"dependencies": {
  "react": "^18.3.0",       // ← version bumped
  "axios": "^1.4.0",
  "lodash": "^4.17.21",
  "zod": "^3.22.4",         // ← new package added
  "date-fns": "^3.0.0"      // ← new package added
}

With syntax highlighting and character-level diffs, version bumps and new packages are immediately obvious. You can share the diff URL with your team — useful when the reviewer can't run git locally.

Best for: Detailed dependency audits, sharing with colleagues, comparing files across different repos.

Method 4: npm diff (npm 8+)

npm 8 introduced a built-in diff command:

npm diff -- package.json

You can also compare specific versions of a package:

npm diff --diff=lodash@4.17.20 --diff=lodash@4.17.21

Best for: Comparing installed package versions when investigating what changed between two npm installs. Less useful for branch-to-branch comparisons.

The Security Angle: Why This Matters Beyond Code Review

Dependency diffs are one of the most underused parts of a security review. When a new package is added to your project, you're trusting that:

The package author hasn't published malicious code
The package's own dependencies are clean
The version you're pinning doesn't have a known CVE

A side-by-side diff makes the attack surface visible. When you see "5 new packages added", that's 5 supply chain vectors to evaluate — much easier to spot in a visual diff than buried in 120 lines of JSON.

After reviewing the diff visually, always run:

npm audit

This cross-references your dependencies against the npm advisory database. A version bump that looks harmless in the diff may resolve — or introduce — a known vulnerability.

Handling Monorepos

If you manage multiple package.json files across a monorepo (apps/web/, apps/api/, packages/ui/), script the extraction:

# Extract package.json files from main branch
git show main:apps/web/package.json > web-main.json
git show main:apps/api/package.json > api-main.json
git show main:packages/ui/package.json > ui-main.json

# Then paste each pair into an online diff tool

This is how version drift gets caught — where apps/web is on React 18.2 and packages/ui is still on React 17, causing subtle incompatibilities that only surface at runtime.

For automated checks across all packages:

for dir in packages/*/; do
  echo "=== $dir ==="
  git diff main..feature -- "$dir/package.json"
done

A Real Code Review Workflow

Here's how this fits into a real PR review process:

Developer opens PR with dependency updates
CI runs npm audit — flags any known vulnerabilities
Reviewer extracts both package.json versions and pastes into a diff tool
Reviewer sees at a glance: 2 new packages (zod, date-fns), 1 version bump (react ^18.2.0 → ^18.3.0)
Reviewer checks the CHANGELOG for new packages
Reviewer confirms the React bump is a minor version (safe)
Approve and merge
After merge: npm install, CI tests pass

This takes 3 minutes. Without the diff, it takes 10 minutes of squinting at JSON, and you're still not confident you caught everything.

Key Takeaways

Use git diff for fast local checks before pushing
Use GitHub's PR view for reviewing changes before merging
Use an online diff tool for detailed audits and sharing
Always diff the lockfile alongside package.json
Run npm audit after any dependency comparison
In monorepos, script the extraction to catch version drift across all packages

What's your workflow for reviewing dependency changes? Drop it in the comments — always curious how teams handle this at scale.

Originally published at online-diff.com/blog/compare-package-json