Diff Viewer
Compare two texts side-by-side with line-by-line diff highlighting. Clearly shows additions ■, deletions ■ and modifications ■. Works with plain text, JSON, YAML, configs and code.
Diff Viewer Overview
The diff viewer compares two blocks of text and highlights the differences between them — additions shown in green, deletions in red — either in a side-by-side layout or inline. For DevOps and SRE engineers, it is an indispensable tool when reviewing configuration changes, comparing Terraform plan outputs, auditing migration scripts, or understanding what changed between two versions of a log file or manifest without needing a full Git repository. The word "diff" comes from the Unix diff utility introduced in 1974, which became the foundation for version control systems and code review workflows.
Step-by-Step Example
Suppose you're investigating config drift on a load balancer. You fetch the live configuration via 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 (LCS) algorithm to identify 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 LCS 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 file in seconds instead of reading line by line.
Why DevOps Teams Use This
- Config drift detection: Compare the running configuration of a service or database against the version checked into source control to identify unauthorised or undocumented changes.
- Terraform and Kubernetes review: Paste before and after versions of a Terraform plan or Kubernetes manifest to get a clear visual of what resources will be changed or replaced.
- Migration script validation: Compare the original SQL schema or data file against the migrated version to verify that only the intended changes were applied.
- Incident investigation: Spot changes in log output between a known-good timestamp and the time of an alert to identify the first anomalous line.
Best Practices & Tips
- Strip volatile fields before diffing API responses: Timestamps, request IDs, and auto-generated UUIDs in JSON responses will show up as noise on every single diff. Remove or normalise these fields first so the real changes aren't buried under expected variance.
- Use side-by-side mode for wide structured configs, inline for narrow logs: Side-by-side preserves the original line structure of YAML/JSON and makes nested indentation changes obvious; inline mode reads better for narrow content like log lines or shell output where horizontal space is wasted in two columns.
- Normalize whitespace and line endings before pasting: A file edited on Windows (CRLF) diffed against one edited on Linux/macOS (LF) will show every single line as changed even if the content is identical. Run inputs through a line-ending normalizer first if you suspect this is happening.
- Diff sorted output when order doesn't matter semantically: Comparing two JSON arrays or env var lists where key order is irrelevant produces a confusing diff if the items are in different orders. Sort both sides identically (e.g., alphabetically by key) before pasting to get a diff that reflects actual content changes only.
Frequently Asked Questions
What diff algorithm does this tool use?
The tool uses a line-by-line comparison algorithm based on the longest-common-subsequence (LCS) approach — the same fundamental algorithm underlying Unix diff and Git's diff engine. It identifies added, deleted, and modified lines between the two inputs. For lines that are present in both texts but with small changes, the viewer applies a secondary word-level diff pass that highlights exactly which tokens within the line were modified, providing precise change identification that is far more useful than just knowing a line changed.
Can I compare Kubernetes YAML files?
Yes. This tool works with any text-based format including YAML, JSON, XML, HCL (Terraform), shell scripts, and plain text. It is particularly useful for comparing before and after versions of Kubernetes manifests — paste the output of kubectl get deployment myapp -o yaml alongside the version from your Git repository to immediately see any configuration drift. The word-level highlighting makes it easy to spot a changed image tag, resource limit value, or environment variable in a lengthy manifest without scanning every line manually.
What is the difference between unified diff and side-by-side diff?
A unified diff (like the output of git diff) shows both old and new content in a single column, using + and - prefixes to indicate additions and deletions — it is compact and works well in terminals and code review systems that render it with colour. A side-by-side diff places the original and modified versions in two parallel columns, making it much easier to visually track which specific lines changed and how, especially in files where edits are scattered across many locations. Side-by-side is generally preferred for reviewing configuration changes, while unified diff is the standard for Git commits and pull requests.