Original
Changed
Differences
Compare two blocks of text and see exactly what changed, line by line, word by word or character by character. Use it when two config files look identical but behave differently, and you need to find the one line out of 40 that differs.
Present in the changed version and not in the original. In line mode the marker covers a whole line. In Words and Characters mode the added text is highlighted in green inside the running text, without a plus sign.
Present in the original and gone from the changed version.
Identical on both sides. These unchanged lines give you the context around each change.
Cut a block from the top and paste it at the bottom, and you get a removal and an addition. A line-based diff treats position as part of the content, so a moved block counts as two edits.
Use Lines for code and config, Words for prose. Lines is the default, and it fits anything where a line is a meaningful unit. Words is better for prose, because a single edited word in a long paragraph would otherwise mark the whole paragraph as changed. Characters is the last resort for invisible differences: a Unicode dash where a hyphen should be, a non-breaking space pasted in from a document, or a trailing carriage return from a Windows editor.
Ignore whitespace helps when one side was reindented and you only want to know whether the content changed. It strips leading and trailing whitespace from each line before comparing, so a block pushed two spaces to the right no longer shows as changed. It also ignores the carriage return at the end of Windows lines, which makes it the quickest fix when one file uses CRLF line endings. Spaces in the middle of a line still count.
The tool computes the longest common subsequence (the longest
run of lines both sides share, in order) of the two inputs, the
same idea behind diff and git diff.
Whatever is not in that shared subsequence is either an addition
or a removal. The comparison runs in your browser, so a
production config or a customer export never leaves your machine.
The work grows with the product of both sizes, so the tool stops
at 2,000 lines per side in Lines mode and 6,000 tokens per side
in Words or Characters mode (in Words mode, each run of spaces
counts as a token too). For larger files, run
git diff --no-index locally.
# Unified diff, the format everything else understands
diff -u old.conf new.conf
# Ignore whitespace-only changes
diff -u -w old.conf new.conf
# Side by side, which is easier to read for short files
diff -y --width=160 old.conf new.conf
# Compare two files with git's algorithm, even outside a repo
git diff --no-index old.conf new.conf
# Only tell me whether they differ at all
cmp -s old.conf new.conf && echo same || echo different// npm i diff
const Diff = require("diff");
const a = "listen 80;\nserver_name example.com;\n";
const b = "listen 443 ssl;\nserver_name example.com;\n";
for (const part of Diff.diffLines(a, b)) {
const sign = part.added ? "+" : part.removed ? "-" : " ";
process.stdout.write(part.value.replace(/^/gm, sign));
}
// Word-level, better for prose
Diff.diffWords("the quick fox", "the slow fox").forEach((p) => {
if (p.added || p.removed) console.log(p.added ? "+" : "-", p.value);
});import difflib
a = open("old.conf").readlines()
b = open("new.conf").readlines()
# Unified diff, same format as the diff command
for line in difflib.unified_diff(a, b, "old.conf", "new.conf", lineterm=""):
print(line)
# How similar are two strings, 0.0 to 1.0
print(difflib.SequenceMatcher(None, "colour", "color").ratio())
# Did they mean one of these?
print(difflib.get_close_matches("recieve", ["receive", "retrieve", "relieve"]))The unified format used by patches, pull requests and git diff carries the same information plus a header per hunk. For example, @@ -12,7 +12,9 @@ means the hunk starts at line 12 and covers 7 lines in the old file and 9 in the new one. patch and git apply read that header along with the context lines to place the change, which is why a patch still applies after unrelated edits elsewhere in the file.
This tool follows the specifications below. Read them when you need the exact normative wording, for example to settle an edge case between two implementations.
It finds the longest common subsequence of the two inputs (the longest run of lines both share, in order), the same idea git diff uses. Whatever is left over is marked as added or removed. A line that only moved still shows as a removal and an addition, because its position is part of the content.
Yes. Set Compare by to Words when two lines differ by a single word and the line view is too coarse to show it. Use Characters for the smallest differences, such as a stray non-breaking space or a curly quote.
Only when you tick Ignore whitespace. It strips leading and trailing whitespace from each line before comparing, so a reindented file or one with Windows line endings stops showing every line as changed. Spaces inside a line still count.
Yes. The comparison runs in your browser and its cost grows with the product of both sizes, so the tool stops at 2,000 lines per side in Lines mode and 6,000 tokens per side in Words or Characters mode. For larger files, git diff --no-index on the command line has no such limit.
Yes, but format both sides with the JSON formatter first so each key sits on its own line. For a comparison that ignores key order, use the JSON diff tool, which compares the parsed structure instead of the text.
Comparing JSON or CSS? Run both sides through the JSON formatter or the CSS formatter first so the structure lines up and the diff stays small. To confirm two files are byte-for-byte identical, compare their hashes in the MD5 generator.