How to compare two texts or files and read a unified diff

Paste two texts or open two files to see what changed, ignore whitespace or case, and learn to read a unified diff, line by line, with a worked example.

On this page

To compare two texts, paste the old one on the left and the new one on the right of a diff checker. It marks the lines that were removed in red, the lines that were added in green, and highlights the words that changed inside an edited line. You can then copy the result as a unified diff, the plain-text format that Git, code review tools and the patch command all use. This article shows the steps, the options that remove noise, and how to read every symbol of a unified diff.

When a diff beats reading

Two versions of a contract clause, a translation before and after a reviewer's edits, a config file that worked yesterday and does not today, two exports of the same list, a script you changed without noting what. Reading both and trying to spot the difference is slow and unreliable, because the eye skips what it expects to see. A diff finds the smallest set of changes that turns one text into the other, and it never gets tired.

Comparing in the browser

Open the diff checker. Both texts stay in your browser, which matters when they hold private documents or credentials.

  1. Paste the original into the left box ("Original text") and the changed version into the right one ("Changed text"). You can also drop a text file onto a box, or press "Open a file". Press "Try an example" to see how it looks.
  2. Read the summary line, for example "2 added, 2 removed, 15 unchanged lines". If the texts are identical it says so.
  3. Switch between "Side by side" and "Inline". Added lines are green, removed lines are red, and inside a modified line the words that changed are highlighted more strongly.
  4. Tick "Ignore whitespace" if someone re-indented the file, or "Ignore upper and lower case" if capital letters do not matter to you.
  5. Press "Copy unified diff", or "Download .diff", to keep the result.

Long runs of unchanged lines are folded into a button, so you see each change with three lines of context around it. If you put the new text on the left by mistake, "Swap sides" flips the colours.

Reading a unified diff

Here is a small settings file before and after an edit. The original:

name = shop
version = 1.4.2

[server]
host = 0.0.0.0
port = 8080
workers = 2

[database]
host = db.internal
port = 5432
pool = 10

[logging]
level = info
file = app.log
rotate = daily

The changed text has version = 1.5.0 on line 2 and level = debug on line 15. The unified diff is:

--- a/original
+++ b/changed
@@ -1,5 +1,5 @@
 name = shop
-version = 1.4.2
+version = 1.5.0
 
 [server]
 host = 0.0.0.0
@@ -12,6 +12,6 @@
 pool = 10
 
 [logging]
-level = info
+level = debug
 file = app.log
 rotate = daily

Every part has a meaning:

  • The first two lines name the two sides. --- is the original and +++ is the changed version. The checker uses a/original and b/changed because it compares pasted text, not files with names.
  • A line starting with `@@` begins a block of changes, called a hunk. In @@ -1,5 +1,5 @@ the part after the minus says "in the original, start at line 1 and show 5 lines", and the part after the plus says the same for the changed text. The second hunk, @@ -12,6 +12,6 @@, starts at line 12 and covers 6 lines on each side.
  • A line starting with a minus exists only in the original: it was removed or replaced.
  • A line starting with a plus exists only in the changed text.
  • A line starting with a space is context: it is the same in both and is there so you can see where you are. Three lines of context surround each change.
  • Two hunks appear because the two edits are separated by more than six unchanged lines. Edits closer together than that are merged into a single hunk.
  • A changed line is a pair: the minus line and the plus line directly after it. Together they say "this line became that line".
  • `\ No newline at end of file` appears under a last line that has no line break after it, when it is involved in a change.

The numbers also add up: a hunk's two counts tell you how many lines were added and removed. If it said -3 +4, one line was added.

Using the diff afterwards

A unified diff is a recipe. On a Mac or Linux, patch app.ini < changes.diff applies it to a copy of the original file and gives you the changed text, which is a way to send someone only the edit and not the whole file. Git understands the same format with git apply, but it expects the file paths in the first two lines to match real files, so edit those two lines first.

Options and what they hide

  • Ignore whitespace. Differences in spaces, tabs and indentation are skipped. Use it to see only what the words did after a reformat, but remember that in some languages and formats, such as Python or YAML, indentation is part of the meaning.
  • Ignore upper and lower case. Useful for comparing names or codes. Do not use it for passwords or case-sensitive identifiers.
  • Line endings never count. A file with Windows line endings and one with Unix line endings compare as equal when the text is the same.

Why two texts that look the same differ

  • Straight versus curly quotes. Word processors replace " with typographic quotes, and a dash with a longer dash. Compare plain text from both sides.
  • A trailing space or a tab. Invisible, but the highlight shows it.
  • A different order. A diff compares in sequence. Two lists with the same items in a different order show up as many changes. Sort both first if order does not matter.
  • JSON with the keys in a different order. Format both with the JSON formatter and tick "Sort keys A to Z" before comparing, so only real differences remain.

Limits

Each side takes up to 5 million characters and a file up to 5 MB, and a file that does not look like text is refused: Word and PDF files must be copied out as text first. If two texts differ in thousands of places the tool cannot match them line by line exactly; it tells you and shows part of the text as replaced, so compare smaller sections. A very long result draws its first 3,000 rows, while the copied unified diff always holds everything.

If you only need to know whether two files are identical

You do not need a diff. Compare their SHA-256 hashes, which is how verifying a download works, and use the diff only when they differ and you want to see why.

Tools mentioned in this article

Back to the blog