Diff Checker

Compare two texts and spot every difference

This diff checker compares two blocks of text and shows exactly what changed — removed text in red, added text in green, and edited lines marked word by word — so you can review edits at a glance. Paste your original and changed versions into the two boxes and the comparison updates instantly, with no Compare button and no waiting. It works for prose, source code, config files, logs, JSON, CSV rows and anything else that is plain text.

Whether you need to compare two texts, diff two revisions of a contract, check what a teammate changed in a file, or line up two spreadsheet columns, this online diff tool lays the two versions next to each other and highlights every addition and deletion for you.

Side-by-side or unified — and word, character or line level

Switch between a side-by-side view that aligns matching lines in two columns and a unified (inline) view that stacks the changes with the familiar +/− markers of a git diff. Side-by-side is best for reading prose on a wide screen; unified is more compact and becomes the default on narrow phones.

Choose the granularity of the highlighting too: Line marks whole changed lines, while Word and Character drill in to show the exact tokens that differ within an edited line — so changing 'color: red' to 'color: blue' highlights only 'red' versus 'blue', not the entire line. Desktop tools like Beyond Compare also offer this, but they require installation and a paid licence.

A real JSON, code and CSV diff checker

Turn on Treat as JSON and both sides are pretty-printed with consistent indentation and sorted keys before they are compared, so reordered keys and formatting noise disappear and only genuine value changes show up — exactly what a json diff checker should do. Diffchecker.com treats JSON as plain text unless you use their paid JSON diff feature; here it's free.

For source code, set granularity to Word or Character and use Inline view to get a clean code diff, then export it as a standard unified-diff patch. Fine-tune the comparison with Ignore whitespace, Ignore case, and Trim trailing spaces to suppress the differences you do not care about and focus on the meaningful edits.

Upload, swap and export

Beyond pasting, you can upload two files or drag and drop them straight onto each box to compare them line by line. Use Swap to flip the original and changed sides, and Clear to start over. When you are done, Copy diff puts a unified-diff patch on your clipboard and Download .diff saves it as a real patch file with @@ hunk headers, ready to attach to a code review or apply with the patch command.

Diff checker alternatives: how we compare

The main diff checker alternatives are Diffchecker.com, WinMerge, Beyond Compare, and KDiff3. Diffchecker.com is browser-based but optionally stores diffs on their servers — a privacy concern for confidential code. Their free tier limits text length and charges for permanent diff links, PDF export, and JSON-aware diffing. WinMerge and KDiff3 are powerful desktop tools but only run on Windows and require installation. Beyond Compare is arguably the best desktop diff tool but costs $30–$60 and only runs on Windows, Mac, and Linux — not a phone.

Our free diff checker runs entirely in your browser, stores nothing on any server, has no character limit, and works on any device including iPhone and Android. JSON-aware diffing, file upload, unified-diff export, and whitespace/case controls are all free with no account. For quick comparisons — code snippets, config files, contracts, CSV columns — it covers the same ground as Diffchecker without the privacy trade-off.

Private by design — nothing is uploaded

Unlike many comparison tools, nothing here is sent to a server. The whole diff is computed in your browser, which means you can safely compare confidential code, contracts or any sensitive document without it ever leaving your device — and it keeps working offline once the page has loaded. That privacy, plus free unlimited length, word- and character-level highlighting, JSON-aware diffing and patch export, is what sets this diff checker apart from server-backed alternatives like Diffchecker.com.

How diff algorithms work: LCS, Myers, and patience diff

Every text diff tool — including this one — is built on the longest common subsequence (LCS) problem: find the longest sequence of lines that appear in both files in the same order, without those lines needing to be adjacent. The lines that are in the LCS are the unchanged context; everything else is an insertion or deletion. Computing the LCS by brute force is exponential, but the classic dynamic-programming solution runs in O(n × m) time and space (where n and m are the number of lines in each file), building up a table of matching subsequences. The 1975 Hunt-McIlroy algorithm — the basis of the original Unix diff command — applied this insight to real files and became the reference implementation that all later tools were measured against.

In 1986 Eugene Myers published a faster approach. The Myers diff algorithm runs in O(ND) time — where D is the number of edits (the "edit distance") — which is dramatically faster in practice when the two files are similar, because D is small. Git uses Myers' algorithm for its git diff output, and most modern code-review tools (GitHub, GitLab, Bitbucket) do the same. For cases where the output readability matters more than raw speed, the patience diff algorithm (used in Bazaar and available in Git via git diff --patience) anchors the comparison on lines that appear exactly once in each file before falling back to LCS. This produces diffs that are far easier for humans to follow when a function is renamed or a block of code is moved, because it avoids the "garbage matches" that LCS can produce when many short lines look alike.

Understanding these algorithms explains behaviours you may notice in practice. Two nearly identical functions can produce a confusing diff if the LCS latches onto a common closing brace or a short comment; switching to patience diff often snaps it into alignment. The edit distance D also determines how fast the comparison feels: diffing two very different files (large D) genuinely takes more CPU than diffing two nearly identical files (small D), which is why very large and very different texts can feel slower to compare.

The unified diff format: reading @@ hunk headers and patch files

The unified diff format — produced by diff -u and by git diff — is the universal language of software patches. Every unified diff begins with two header lines: --- a/filename identifies the original file (with its timestamp or a/ prefix in Git) and +++ b/filename identifies the new file. After the headers come one or more hunks, each introduced by an @@ hunk header of the form @@ -a,b +c,d @@. This means: starting at line a of the original file, spanning b lines; starting at line c of the new file, spanning d lines. Lines prefixed with a space are unchanged context lines (three on each side by default — enough to uniquely locate the hunk in the file). Lines prefixed with - were removed; lines prefixed with + were added.

This format is universal because it is both human-readable and machine-applicable. The patch command reads a unified diff and applies it to the original file to produce the new version — it uses the context lines to find the right location even if the surrounding line numbers have shifted. The -p flag controls how many leading directory components to strip from the file paths in the header (e.g., patch -p1 strips the a/ prefix that Git adds). When you click Download .diff in this tool, you get a valid unified-diff patch in exactly this format, ready to be applied with patch, reviewed in a pull request, or archived as a record of changes.

Understanding the hunk header is also useful for reading large diffs. Instead of scrolling through every line, check the @@ numbers to jump to the region that changed, and use the context lines as landmarks. Code-review tools like GitHub's pull request viewer parse these headers to render inline comments at the exact line that changed, which is why a downloaded .diff file from this tool can be pasted directly into a GitHub review or sent as a patch email to a mailing list.

Word-level and character-level diff: the diff-within-a-diff

Standard line-based diffing treats each line as an atomic unit: if a single word changes, the whole line is marked as removed and re-added. That is fine for code reviews where you want to see complete changed statements, but it obscures small edits in prose. Word diff (exposed in Git as git diff --word-diff) applies a second LCS pass within each changed line, treating whitespace-delimited tokens as the units of comparison. The result is that changing "the quick brown fox" to "the slow brown fox" highlights only "quick" versus "slow" inside the line rather than the entire sentence. This is the default Word granularity in this tool and is the most useful setting for prose editing, release notes, or documentation reviews.

Character-level diff goes one step further, treating every individual character as the unit of comparison. This is most valuable for single-line comparisons where the content is dense and positional — a changed URL, a CSV field value, a date string, a database connection string, or a hexadecimal hash. At character level, changing 2024-06-19 to 2024-06-20 pinpoints the single digit that changed rather than flagging the whole string. The cost of finer granularity is visual noise: at character level a sentence with several small tweaks can become hard to read because the highlighting is fragmented. The right level depends on the content — line diff for code review, word diff for prose, character diff for data validation — which is why this tool exposes all three as a toggle.

The interplay between levels also explains why semantic diff tools are a growing area. For source code, even word diff can be misleading because programming languages have structure that whitespace does not capture — a renamed variable appears as many small word changes spread across a file rather than one conceptual change. Tools like GumTree operate on the abstract syntax tree (AST) rather than raw text, grouping changes by the program element they belong to. AST-aware diffing is especially powerful for automated refactoring audits where you want to confirm that a rename touched exactly the right identifiers and nothing else.

Diff beyond code: legal redlines, config drift, and data validation

Diff tools were invented for source code but the underlying algorithm is domain-agnostic — any document that can be represented as lines of text benefits from precise change tracking. Legal contract redlining is one of the highest-stakes applications: lawyers comparing two negotiated drafts of an agreement need to know exactly which clauses were added, removed, or reworded, and a line-level diff with word highlighting gives that precision faster and more reliably than manually reading both versions. Many firms use Word's Track Changes for this, but a plain-text diff checker is far more trustworthy on documents exchanged in different word-processor formats, where invisible formatting changes can obscure or invent differences.

Configuration management and infrastructure-as-code workflows depend on diffing heavily. Before applying an Ansible playbook, Terraform plan, or Kubernetes manifest, teams diff the proposed file against the current deployed version to audit exactly what will change — a missing indentation level, a changed port, or an added environment variable can all have production impact. Diffing a before.json and after.json snapshot of a Terraform state file is a common pattern for verifying that a deployment did only what was intended. Similarly, comparing two CSV or JSON data exports — for example, two snapshots of a product catalogue or a database table — shows which rows were added, removed, or had field values modified between exports, a task that is tedious and error-prone in a spreadsheet but immediate with a diff tool.

Web page monitoring and competitive intelligence are another practical use case: periodically fetching the text of a competitor's pricing page, a government regulatory notice, or a legal terms-of-service and diffing successive fetches reveals when prices changed, when new clauses were added, or when a product was quietly discontinued. Academic and commercial plagiarism detection systems use a variant of the same idea — computing similarity scores between a submitted document and a corpus of known texts — though at that scale the comparison is probabilistic rather than exact. In all these cases the underlying insight is the same one that Unix diff demonstrated in 1975: representing change as a minimal set of additions and deletions to a baseline is more informative, more auditable, and more actionable than storing or presenting two full copies side by side.