Diff Checker

The diff checker compares two pieces of text and shows exactly which lines differ. Paste the original (the 'before' version) into the left text box and the modified (the 'after' version) into the right; the tool runs an LCS-based diff and highlights every difference within milliseconds. Added lines appear green, removed lines red, changed lines show character-level highlighting on the substring that actually changed. A summary line at the top reports the count of added, removed and changed lines plus a similarity percentage. Use it for any plain-text comparison: source code, JSON config, YAML manifests, CSV exports, log files, Markdown drafts, plain prose. The tool handles UTF-8 input up to several megabytes per side without breaking. Most importantly: every byte of computation runs locally in your browser. Nothing is sent to a server, nothing is logged, nothing leaves your device — safe for proprietary code, internal documents and confidential data.

Step 1: Paste the original text into the left box. This is the 'before' version — the file as it existed prior to changes, the original draft, the previous config. Use Ctrl+A then Ctrl+C from any text editor or browser to grab the text, then Ctrl+V into the diff checker. Step 2: Paste the modified text into the right box. This is the 'after' version — the edited file, the new draft, the updated config. The diff is computed automatically as soon as both sides have content. Step 3: Read the result. Green lines are additions present in the right but not the left; red lines are removals present in the left but not the right; lines with character-level highlighting are 'changed' (a remove + add pair on similar content). The summary at the top gives a high-level view: added count, removed count, and a similarity percentage from 0% (no overlap) to 100% (identical). Toggle 'ignore whitespace' if the only changes are reformatting; toggle 'ignore case' if you don't care about Hello-vs-hello distinctions.

Diff tools work at one of three granularities: line, word, or character. Line-by-line is the universal default for code and configuration: each line is treated as a unit, and the diff identifies which whole lines were added, removed or substantively changed. This is what GNU diff, git diff, GitHub PRs and IDE diff views all show. Word-by-word (sometimes called 'word diff') splits text on whitespace boundaries — better for prose where edits often occur within sentences. Character-by-character is the finest granularity, used internally by most diff tools to highlight the exact substring that differs within a changed line. The tool above shows line diff as the primary view and character diff as the highlighting on changed lines — the same two-level approach VS Code, JetBrains and GitHub use. Use line diff for code review, word diff for prose editing, character diff only for short comparisons (single sentences, identifiers, URLs).

Source code is the most common diff use case — every code review, every PR, every git commit involves diffing code. The diff checker handles any programming language because the LCS algorithm is language-agnostic: JavaScript, TypeScript, Python, Go, Rust, Java, Kotlin, Swift, C, C++, C#, PHP, Ruby, Scala, Elixir, Clojure, shell scripts, Dockerfiles, Terraform HCL, SQL — all work the same way. Best practice for code diffs: format both sides with the same code formatter (Prettier for JS/TS, Black for Python, gofmt for Go, rustfmt for Rust) before pasting, so that whitespace and style differences don't pollute the real semantic diff. If you can't reformat, use the 'ignore whitespace' option to skip leading/trailing whitespace differences. For diffing across language boundaries (comparing a Python implementation to a Go port, for example), the line diff still works but the similarity percentage will be misleading — the meaningful unit is structural similarity, not line overlap.

JSON diff is one of the highest-demand use cases — comparing API responses, config files, package.json files, and structured data exports. Important pre-step: format both sides identically. Pretty-print with the same indent (typically 2 or 4 spaces) and sort object keys alphabetically. Without normalisation, a structurally-identical JSON document can produce a wildly noisy diff just because the keys are in different order. Tools to normalise: jq with the --sort-keys flag, Python's json.dumps with sort_keys=True, jsonformatter.org. For semantically-aware JSON diffing (where {a:1, b:2} and {b:2, a:1} are equal), dedicated tools like json-diff (npm), jq, or RFC 6902 JSON Patch produce better output than line diff. The line-diff tool above works well for JSON when both sides are pre-normalised; if you regularly need semantic JSON diff, consider a JSON-aware library in your stack.

YAML and CSV are line-oriented formats that diff cleanly with line-based tools — usually with less noise than JSON because YAML doesn't have braces and CSV has consistent row structure. YAML diff tips: ensure both sides use the same indentation (2 vs 4 spaces matters; YAML is whitespace-significant), the same key order convention, and the same quoting style for strings. For Kubernetes manifests, Docker Compose files and CI workflow YAML, the line diff above is the standard tool used in every code review. CSV diff tips: ensure both files use the same delimiter (comma, semicolon, tab), the same line endings (LF vs CRLF — many CSVs from Excel use CRLF), the same column order, and matching headers. For large CSVs (>10,000 rows), specialised tools like csvdiff (Aswinkarthik) or daff (paulfitz) produce structured diffs showing which row and column changed; for smaller files the line diff above is fast and simple.

All modern diff tools rely on the LCS (Longest Common Subsequence) family of algorithms. The original diff algorithm was published by James Hunt and Doug McIlroy at Bell Labs in 1976 — the same paper that produced the Unix 'diff' command still in use today. In 1986, Eugene Myers published 'An O(ND) Difference Algorithm and Its Variations', which optimised LCS for the common case of small differences in large inputs. Myers' algorithm runs in O((N+M)D) time where N+M is the total input size and D is the number of edits — much faster than the naïve O(N×M) for typical real-world diffs (where D is small relative to N+M). GNU diff, git diff, libxdiff (used by Mercurial, Subversion, GitHub) all implement Myers or the closely-related 'patience diff' and 'histogram diff' variants. The diff checker above uses a JavaScript LCS implementation tuned for browser performance — fast enough for inputs up to several megabytes per side.

There are two dominant ways to display a diff: side-by-side (split view) and unified. Side-by-side puts the original and modified versions in two columns with changes aligned horizontally — easier for human reading because you can see both versions at once and the visual grouping makes structure obvious. This is the default in IDEs (VS Code, IntelliJ), GitHub PRs (in 'split' mode), and most online diff tools. Unified diff stacks removed and added lines in a single column with '-' and '+' prefixes plus 3 lines of unchanged context above and below — more compact, scriptable (it's the patch file format that 'git apply' and 'patch' consume), and the default in command-line tools and email-based code review (Linux kernel mailing list, etc). Pick side-by-side for visual review of small-to-medium changes; pick unified for compact display of large rewrites, for copying as a patch file, or for sharing in text-only contexts (chat, email, terminal).

Document comparison covers a wide range: tracking what an editor changed in a draft, comparing two versions of a contract, checking what was paraphrased vs copied (lightweight plagiarism detection), or auditing translation drift. Use the diff checker for any plain-text document. For Microsoft Word .docx files, export to plain text first (File > Save As > Plain Text in Word, or Format > Plain Text in LibreOffice). You'll lose formatting (bold, italics, headings) but you'll catch every text change. For PDF documents, use a PDF-to-text converter first (pdftotext from poppler-utils, or browser-based tools), then diff the extracted text. For Google Docs, use the built-in Version History (File > Version history > See version history) which shows authorship-tracked diffs natively. For long-form prose where line breaks are arbitrary, consider word-level diff tools (diff --word-diff in git) — they ignore line wrapping and surface real word-level changes.

Privacy matters when diffing proprietary code, internal documentation, financial records, customer data or any confidential text. Many online diff tools upload the input text to their server for processing — convenient but a real risk for sensitive content. The diff checker on this page is fully client-side: the LCS algorithm runs in JavaScript inside your browser, no fetch() call ever leaves your device, no log entry is created on any server. Verify this yourself by opening DevTools > Network tab and pasting text — you'll see zero outbound requests. For maximum privacy on highly sensitive content, use a local tool that never touches the network: GNU diff (preinstalled on Linux/macOS), git diff (any repository), VS Code's built-in diff, JetBrains IDEs' diff, Beyond Compare. For one-off comparisons of less-sensitive text, a verified browser-based tool like the one above gives the convenience of a web tool with the privacy of a local one.

For developers, diff is daily infrastructure — code review, PR review, merge conflict resolution, comparing config across environments, debugging 'what changed' regressions. Use git diff for tracked changes (git diff, git diff --staged, git diff main..feature, git diff HEAD~3); use the online diff checker above for ad-hoc comparisons (someone pastes a snippet in Slack, you compare an env-var dump from staging vs prod, you check a colleague's local config against your own). For merge conflict resolution, three-way diff tools (kdiff3, p4merge, VS Code's built-in three-way view) outperform two-way diff because they show the common ancestor in addition to both sides. For code review at scale, GitHub PRs, GitLab MRs and Gerrit all use the same line-based LCS diff under the hood — what you see in a PR is the same algorithm you can run locally with git diff or paste into the online tool above. The diff is reproducible across tools: same inputs always produce the same diff.

Both produce mathematically equivalent LCS-based diffs — the underlying algorithm is the same. Use git diff when: you have files in a git repository, you want to compare commits/branches/staged changes, you need to script the diff (CI checks, pre-commit hooks), you need history-aware comparison (git log, git blame), or you're producing a patch file (git format-patch). Use an online diff checker when: you have raw text not in a repo (a snippet from chat, an API response, a config dump), you want a quick visual side-by-side without setting up a repo, you're comparing across systems where git isn't available (someone on a Chromebook, a code-review meeting), or the content is sensitive and you want a verified browser-only tool with no network calls. Both tools belong in a developer's toolkit; neither replaces the other. The online tool's killer features are zero setup and visual side-by-side; git's killer features are history awareness and ecosystem integration.