What is a code diff tool?
A code diff tool compares two versions of a text and shows what changed between them. This one works line by line: it finds the longest run of lines the two versions share, in order, and marks everything else as removed from the original or added in the changed version. It works for source code, config files, CSV rows, word lists or prose.
How to compare two texts
- Paste the older version into the Original box.
- Paste the newer version into the Changed box.
- Click Compare.
Every line from both versions appears in the output once, in order, with a two-character prefix:
| Prefix | Color | Meaning |
|---|---|---|
| (two spaces) | none | The line is in both versions |
- |
red | The line is only in the original (removed) |
+ |
green | The line is only in the changed version (added) |
If the two texts are identical, you get "No differences found." instead. An empty box counts as zero lines, so leaving Original empty lists every line of the changed version as +, and leaving Changed empty lists every original line as -.
Worked example
Original:
function greet(name) {
console.log("Hello " + name);
return true;
}
Changed:
function greet(name, greeting) {
console.log(greeting + " " + name);
return true;
}
Output:
- function greet(name) {
- console.log("Hello " + name);
+ function greet(name, greeting) {
+ console.log(greeting + " " + name);
return true;
}
The first two lines changed, so their old versions are listed as removed and their new versions as added. The last two lines match and are shown with a leading space. When removals and additions sit at the same spot, the removals come first.
How the comparison works
The tool computes a longest common subsequence (LCS) of lines: the largest set of lines that appear in both texts in the same order. Those lines are "unchanged", and anything outside that set becomes a - or + line. Git's default diff algorithm, Myers' algorithm, solves the same problem more efficiently on large files (git diff documentation), so the results here usually match what you'd see in a code review, though ties can be broken differently.
A few consequences of comparing whole lines exactly:
- Moved lines show as a removal plus an addition. If
threemoves from the end of a list to the top, the output shows+ threeat the top and- threeat the bottom. - Whitespace and case count.
aanda(trailing space) differ, and so doaandA. - Reformatting looks like a rewrite. Re-indenting a file changes almost every line, so the real edit gets lost among them.
- No hunks. Unlike
git diffor the unified format, the output shows the whole file rather than a few lines of context around each change, and there are no@@line-number headers. It's meant for reading, not for applying as a patch.
Getting a cleaner diff
Most noisy diffs come from formatting rather than content. Normalize both sides the same way before comparing:
- For JSON, run both versions through the JSON formatter. Minified and pretty-printed copies of the same data then compare as identical, and only real value changes remain.
- For HTML, CSS or JavaScript, use the code beautifier on both sides so indentation and line breaks match.
- For lists where order doesn't matter, such as email lists or package names, sort both sides with the text sorter first. Then the diff shows only items that are genuinely missing or new.
- To see which lines a clean-up removed, paste your list before and after using Remove Duplicate Lines. Every dropped copy shows up as a
-line.
Size limit
Comparing every line against every other line uses memory in proportion to the two line counts multiplied together, so the tool stops at 250,000 line pairs. Two 500-line files fit; two 501-line files don't, and neither do 1,000 lines against 300. For larger files, compare one function or section at a time, or use git diff --no-index old.txt new.txt on your own machine, which handles files of any size.
Last updated