Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path
Diff Checker
A text diff checker. Paste an original and a changed version to see a line-by-line comparison — additions, removals and unchanged lines highlighted — computed with a longest-common-subsequence diff, entirely in your browser. Handy for comparing configs, logs, JSON, or any two versions of text.
Finding what changed between two texts is not as simple as comparing line one to line one. Insert a single line at the top and a naive comparison reports every following line as changed. This checker anchors on the lines both versions share, in order, and reports only what falls outside them.
What it computes
Both inputs are split into lines at each newline. The tool then fills a table of longest-common-subsequence lengths, where each cell answers how many lines the rest of the original and the rest of the changed text have in common:
L[i][j] = 0 past the end of either text
= L[i+1][j+1] + 1 if a[i] equals b[j]
= max(L[i+1][j], L[i][j+1]) otherwiseIt then walks both texts from the top. Equal lines are output as unchanged and both sides advance. Otherwise it drops the original’s line as a removal if doing so keeps the longest common run, and takes the changed text’s line as an addition if not; on a tie it removes first, so a removal is listed before the addition that replaces it. Leftover lines at the end are removals or additions. The bar above the output counts each kind.
The table has one cell per pair of lines, so for very large inputs, more than 4 million pairs such as two files of over 2,000 lines each, the tool falls back to marking every original line removed and every changed line added.
A worked example
The defaults compare a three-line original with a four-line changed version:
| Original | Changed |
|---|---|
const port = 3000; | const port = 8080; |
const host = "localhost"; | const host = "localhost"; |
start(host, port); | const tls = true; |
start(host, port); |
The longest common subsequence is two lines long: the host line and the start line. Everything else is an edit, and the output reads:
- const port = 3000;
+ const port = 8080;
const host = "localhost";
+ const tls = true;
start(host, port);The counters show +2 and −1. The changed port is one removal plus one addition, because the tool compares whole lines, and the new tls line is a pure addition slotted between two unchanged lines. Press Swap and the same comparison runs in reverse: +1 and −2.
Assumptions and limits
- Exact matching. Case, spaces, tabs and invisible characters all count. A trailing space or a Windows carriage return makes two lines different.
- No inline highlighting. An edited line is shown as removed and re-added; the changed characters inside it are not marked.
- No move detection. A block moved elsewhere appears as a removal in one place and an addition in another.
- Quadratic cost. Time and memory grow with the product of the two line counts, which is why very large inputs get the coarse fallback.
- Ties are resolved one way. When several minimal diffs exist, the tool always prefers removing first, so it can group edits differently from other tools.
How to use the result
- Normalize first. Format both sides the same way, sort JSON keys and strip trailing whitespace, so the diff shows meaning rather than formatting.
- Read pairs as edits. A removal directly followed by an addition is usually one changed line; compare the two by eye to spot the exact characters.
- Check the counts. A large count on a small change usually means a whitespace or line-ending mismatch, not real edits.
- Diff config before deploying. Comparing the current and proposed file is a quick review that catches stray edits.
How it works
- Line-by-line comparison via a longest-common-subsequence diff.
- Additions, removals and unchanged lines marked, with + and − counts.
- Finds a minimal set of line edits, the same goal git’s diff has.
- Runs entirely in your browser; nothing is uploaded.
Frequently asked questions
How does the diff decide what changed?
It computes the longest common subsequence of the two texts, line by line: the longest sequence of lines that appears in both versions in the same order. Lines in that sequence are shown as unchanged, lines found only in the original are removals, and lines found only in the changed version are additions. Anchoring on the common lines is what stops one inserted line at the top from making every later line look different, which is what a naive line-1-to-line-1 comparison would report.
Is this the same algorithm git uses?
It solves the same problem but not in the same way. Finding the longest common subsequence is equivalent to finding the smallest set of line insertions and deletions, which is what git’s default Myers algorithm also finds, only much faster on large files. When several equally small edit scripts exist, tools can choose differently, so this checker and git may group a change slightly differently while counting the same number of added and removed lines.
Is my text sent anywhere?
No. Both inputs are compared entirely in your browser with JavaScript; nothing is uploaded, logged or stored by the tool. That makes it reasonable to diff configuration files, logs or other sensitive text, though you should still follow your organization’s rules for handling secrets. When you close or reload the page, the text is gone, because the inputs are not saved anywhere, including your browser’s storage.
Does it diff word by word or line by line?
Line by line. That is the right granularity for code, configuration, logs and structured data, where a change usually means a whole line was added, removed or edited. An edited line shows as one removal followed by one addition, without highlighting the changed characters inside it. Word-level or character-level diffing suits prose better, but it gets noisy on code, where a renamed variable would otherwise light up dozens of fragments.
Why does it show differences in lines that look identical?
Because the comparison is exact. A trailing space, a tab instead of spaces, a different quote character or a Windows line ending all make two lines unequal even when they look the same on screen. Windows files end each line with a carriage return before the newline, so a file saved on Windows and the same file saved on Linux can differ on every line. Normalize whitespace and line endings on both sides before comparing if only content matters.
Can I compare JSON or formatted data?
Yes. Paste both versions and it diffs them line by line. For the cleanest result, format both sides the same way first, with consistent indentation and key order, so only real value changes show up rather than formatting noise. Two pretty-printed JSON documents with sorted keys put each field on its own line, which turns the diff into an exact list of the fields that were added, removed or changed.