Diff Checker

A better way to compare text

How to compare two texts

Paste the original version into the left editor and the changed version into the right one — or drag a file onto either panel. The comparison runs as you type: removed lines are marked on the original side, added lines on the changed side, and any line that was merely edited gets word-level marks showing exactly which words moved. The stats bar above the result summarizes how many lines were added, removed and changed, the Swap button flips the two sides when you pasted them in the wrong order, and Load sample fills both editors with example text so you can see how the views behave before using your own.

Side-by-side or inline — which view to pick

The two-column split view keeps each version whole, which works best for reviewing code where surrounding context matters. The unified inline view interleaves removals and additions in a single column, which is easier to scan on a narrow screen and closer to what git diff prints in a terminal. Line-based comparison like this finds the longest stretches both texts share and marks everything between them as changes — that is why moving a paragraph shows up as a removal in one place and an addition in another rather than as a "move."

Getting cleaner comparisons

Noise hides real changes. If one file uses tabs and the other spaces, or the only differences are re-wrapped lines, switch on Ignore whitespace to silence them; Ignore case does the same for capitalization-only edits, which is handy for prose and SQL. For structured data, normalize before comparing — pretty-printing both JSON payloads with the JSON Studio first turns a one-line blob into a readable line-per-key diff. Typical jobs this tool handles well: spotting what changed between two config or .env files, reviewing a colleague's edit to a document, checking which API response fields changed between deployments, and comparing log excerpts from a working and a failing run.

Reading the result: gutters, signs and stats

Each row of the result table starts with line numbers — two gutters in split view (original on the left, changed on the right) and two side-by-side gutters in inline view — followed by a sign column: a minus for removed lines, a plus for added lines and nothing for unchanged ones. A line that appears in both versions but was edited is rendered as a paired removal and addition, with <del> and <ins> marks around the exact words that differ. The stats bar counts every added and removed line (an edited line counts once on each side), lists how many lines are unchanged, and shows a green "identical" badge when both inputs match byte for byte — useful for confirming that two exported files really are the same. Line counts in each editor header let you spot the crude signal first: if one file reports 212 lines and the other 213, you are probably looking for a single insertion.

Real-world use cases

• Environment drift. Paste the staging .env on the left and production on the right. Changed values light up word by word, so REDIS_URL=redis://cache-1 versus cache-2 is obvious even in a fifty-line file. Because nothing is uploaded, secrets stay on your machine.
• Contract and copy review. Drop two versions of a Word export saved as plain text, or two drafts of a legal clause, and switch on Ignore whitespace so reflowed paragraphs do not drown the actual wording changes.
• API regression checks. Pretty-print yesterday's and today's JSON response with the JSON Studio, paste both, and look only at the plus and minus rows. A missing or renamed key shows as a removal paired with an addition on the same row.
• Merge-conflict triage. Paste the "ours" block on the left and "theirs" on the right to see the real delta without the conflict markers, then decide which side to keep.

How the comparison algorithm works

The tool splits both texts on newlines and builds a longest-common-subsequence (LCS) table, the same dynamic-programming approach that classic diff and Git's default algorithm build on. Walking back through that table yields a sequence of "same", "delete" and "add" operations that preserves the most shared lines; neighbouring delete and add runs are then paired up so that each replaced line can be compared a second time at word granularity, where whitespace runs are kept as separators and only non-space tokens are marked. When Ignore whitespace or Ignore case is on, the normalised copies are used for matching while the original text is still what gets displayed — so you see your real indentation and capitalisation, just not flagged as changes.

Because the table is quadratic in size, very large inputs — tens of thousands of lines on each side — take noticeably longer and use more memory; comparing a few thousand lines stays instant. Rendering is debounced by 120 ms so typing in either editor feels smooth, and the browser never sends a byte to any server. One known limitation of LCS diffing is that it has no concept of moves: a block that was cut from the top and pasted at the bottom is reported as a removal plus an addition, exactly as Git does without --color-moved.

Further reading

If the differences you see are only formatting, minify vs beautify explains how to normalise code before comparing it. Comparing exported spreadsheets or API dumps? CSV, JSON and XLSX conversion pitfalls covers the encoding and quoting issues that produce phantom diffs. Browse all guides for more.

Frequently asked questions