Text & Code Diff Checker
Compare two versions and get a unified diff, the format git and patch read, with optional whitespace and case blindness.
# 3 added, 2 removed, 3 unchanged
# 5 lines against 6
--- original
+++ changed
@@ -1,5 +1,6 @@
-function greet( name ) {
- return 'Hello ' + name;
+function greet( name, greeting = 'Hello' ) {
+ return `${ greeting } ${ name }`;
}
greet( 'world' );
+greet( 'WordPress', 'Hi' );Output is valid and updates as you type.
Fix the highlighted fields to update the output.
Compare two versions and get a unified diff: the same format git diff prints and patch applies.
How to use
- Paste the original on the left and the changed version on the right. Nothing is uploaded.
- Read the counts first. Added, removed and unchanged lines, and the length of each side.
- Adjust the context if the hunks are hard to place. Three lines either side is what git uses; zero shows only the changes.
- Turn on whitespace blindness when a reformat is hiding the real change. The comparison ignores spacing, and the printed lines keep their own, so the diff still applies.
- Copy the diff. Saved as a
.difffile it can be applied withpatch -p0 < changes.diff.
Example
--- original
+++ changed
@@ -1,3 +1,3 @@
-function greet( name ) {
- return 'Hello ' + name;
+function greet( name, greeting = 'Hello' ) {
+ return `${ greeting } ${ name }`;
}@@ -1,3 +1,3 @@ says the hunk starts at line 1 on both sides and covers three lines of each. A - line was removed, a + line was added, and a line starting with a space is unchanged context.
Pitfalls
- A line diff cannot see inside a line. Changing one word marks the whole line removed and added, which is why a reformatted file looks entirely rewritten.
- Whitespace blindness is for reading, not for applying. The diff still contains the real lines, so applying it changes the spacing too.
- Line endings are a real difference. This normalises CRLF and CR to LF before comparing, so a file converted between Windows and Unix does not show every line as changed.
- A trailing newline is invisible and matters.
patchcares, and so does git; this treats a file ending in a newline as having no final empty line. - Moved blocks show as a deletion and an addition. That is what a unified diff is: git’s move detection is a display layer on top of the same algorithm.
- Indentation changes are changes. If your team argues about tabs, a diff is where the argument becomes visible.
- Two files with the same content in a different order are almost entirely different to a line diff. Sorting both first is a legitimate way to compare sets of lines.
- Large inputs are fine up to a point: the algorithm costs time in proportion to the number of differences, so two similar 10,000 line files are fast and two unrelated ones are not.
Compatibility
The output is a unified diff with the usual ---, +++, @@ and prefix conventions, readable by patch, git apply and every review tool. The algorithm is Myers’, the same one git uses, so the hunks match what git would produce for the same input in most cases; git additionally applies heuristics to prefer certain split points. Everything runs in your browser.
Frequently asked questions
Can I apply this diff with patch?
patch -p0 < changes.diff from the directory holding the original file.