Diff Viewer

Wiring Diffs Into Review Workflows

This viewer is built for pasting two arbitrary blocks of text that don't live in a Git repository — a live API response, a config fetched from a running server, output copied from a support ticket — situations where git diff has nothing to compare against. That makes it a natural companion to, not a replacement for, source-controlled review workflows: use it to spot-check drift between a deployed configuration and what's checked into Git, or to compare two versions of an object pulled from different environments before deciding whether a change needs to be committed at all. Once a difference is confirmed here and needs to become a tracked change, the actual fix still belongs in a pull request reviewed through your normal Git-based process, where the diff is versioned, attributed, and auditable — this tool is for the investigation step before that, not a substitute for it.

Walking Through a Config Drift Diff

Suppose you're investigating config drift on a load balancer. You fetch the live configuration through its API and paste it into the left pane, then paste the version checked into Git on the right. The viewer splits each input into an array of lines and runs a longest-common-subsequence algorithm to find the maximal set of unchanged lines. A line present only in the live config — say timeout: 60 — is marked as deleted, shown in red, while the Git version's timeout: 30 is marked as added, shown in green, directly below it.

Because both lines share the word "timeout:", the viewer's secondary word-level pass highlights only the 60 versus 30 token as changed rather than flagging the entire line, letting you spot the exact value drift in a 200-line config in seconds instead of reading line by line. If the two files instead differed only by an extra blank line inserted near the top, every subsequent line would otherwise misleadingly appear "changed" purely due to the shift — which is exactly why line-based diffing, rather than naive character-position comparison, is the right approach for structured configuration files.

Diffs That Lie: Where Comparisons Go Wrong

• Volatile fields drowning out real changes: timestamps, request IDs, and auto-generated UUIDs in JSON responses show up as noise on every single diff — strip or normalize these fields first so genuine changes aren't buried under expected variance.
• Mismatched line endings creating a wall of red: a file edited on Windows (CRLF) diffed against one edited on Linux or macOS (LF) shows every line as changed even when the content is identical — normalize line endings before pasting if this looks like what's happening.
• Unsorted arrays or key-order differences: two JSON arrays or env var lists that are semantically identical but ordered differently produce a confusing diff full of false changes — sort both sides identically before comparing when order doesn't matter.
• Comparing pretty-printed output against minified output: a config formatted with 2-space indentation diffed against the same config minified to one line will appear completely rewritten — run both sides through the same formatter first to get a diff that reflects content, not formatting.

How This Relates to git diff and diff -u

The algorithm underneath this viewer is the same longest-common-subsequence approach that powers the Unix diff utility, introduced in 1974, and by extension git diff. The practical difference is scope, not math: git diff and diff -u compare two versions of a file that both exist as identifiable objects — commits, working-tree versions, or files on disk — and output a unified patch format with +/- line prefixes designed to be applied back with patch or reviewed in a terminal. This tool compares two arbitrary pasted blocks that were never files at all, and renders the result as a two-column visual comparison rather than an appliable patch — useful specifically when you want to see a difference, not generate a patch file to apply it.

Diffing Large Files Without Choking the Browser

Line-by-line LCS comparison scales roughly with the product of the two inputs' line counts in the worst case, so pasting two multi-thousand-line files can noticeably slow the comparison down compared to the near-instant result you get on a typical 50-200 line config file. In practice, most DevOps use cases — comparing a Kubernetes manifest, a Terraform plan section, or a load balancer config — stay well within a range where this is imperceptible, since these files rarely run past a few hundred lines. For genuinely large files, such as a multi-megabyte log dump, it's faster and more useful to pre-filter down to the relevant section with grep or a log-search tool before pasting into the diff viewer, rather than asking a browser tab to render a wall of thousands of mostly-identical lines.

Frequently Asked Questions