File Compare

Upload two text files and see the differences highlighted line by line, entirely in your browser, with whitespace and case options for noisy comparisons.

Two different files can be reported as identical

This tool reads both files as text, which is the right choice for the job it does and has one consequence worth knowing. Decoding as UTF-8 replaces anything that is not valid UTF-8 with U+FFFD, the replacement character. There is one of those and a great many invalid byte sequences, so the mapping loses information. Every possible file of one and two bytes, decoded and counted:

File lengthPossible filesDistinct textsCollapse
1 byte 256 129 49.6%
2 bytes 65,536 18,562 71.7%

All 128 bytes from 0x80 to 0xFF are invalid on their own, so that many different one-byte files decode to exactly the same single character. The 128 ASCII bytes plus one replacement character leaves 129 possible outcomes from 256 inputs. Put a file containing the byte 0x80 in one box and one containing 0xFF in the other, and this page will tell you they are identical — because after decoding, they are.

The share lost grows with length rather than shrinking, since a longer run gives more chances to contain an invalid sequence and every one of them collapses onto the same character. None of this matters for the text files the tool is for, where decoding is lossless and the comparison exact. It matters a great deal the moment someone drags in a PNG or a zip, which is a thing people do.

And line endings decide the answer before the text does

The comparison splits on the newline character alone. A file saved on Windows ends each line with a carriage return first, and that carriage return stays attached:

Saved onWhat the split produces
Unix or macOS["alpha","beta","gamma",""]
Windows["alpha\r","beta\r","gamma\r",""]

The same three lines of text, and 3 of the 4 entries differ — everything except the trailing empty one. The comparison reports the whole file as rewritten. Strip the carriage returns first and the count drops to 0: identical. This is the most common reason a diff shows a whole file changed when nothing in it did, and it scales with the size of the file rather than the size of the change.

A trailing newline behaves the same way, because splitting leaves an empty entry after a final separator:

File contentsSplit resultLines counted
"a\nb" ["a","b"] 2
"a\nb\n" ["a","b",""] 3
"a\nb\n\n" ["a","b","",""] 4
"" [""] 1

So a file ending with a newline has one more line than one that does not, and an empty file has one line rather than none. That is why adding a final newline shows up as a change even though nothing visible moved, and why so many projects settle the argument by requiring one.

How to use

  1. Choose the two files you want to compare.
  2. Read the highlighted differences.
  3. Ignore whitespace if formatting changed but content did not.
  4. Check the line-ending report if everything shows as changed.

Frequently asked questions

Do my files get uploaded?

No. Both files are read and compared entirely in your browser, so nothing is transmitted. That matters for configuration files, exports and drafts that would be unwise to hand to an unknown web service.

Why does every line show as different?

Almost always line endings — one file saved with Windows CRLF and the other with Unix LF differ invisibly on every line. A change of indentation from tabs to spaces does the same. Both are worth checking before assuming the content really changed.

Can I compare binary files?

Not usefully. A line-based comparison assumes text, and applying it to an image or an executable produces noise. Comparing binaries meaningfully needs a tool that understands the format, or at minimum a byte-level view.

What size of file can this handle?

Comfortably up to a few megabytes. Beyond that the browser slows noticeably, since the whole comparison is held in memory. For very large files a command-line diff is the better tool.

Should I ignore whitespace?

It depends what you are checking. Ignoring it is right when reviewing a reformatted file for real changes. It is wrong for Python, YAML or Markdown, where whitespace carries meaning and an indentation change is a substantive one.

Why is the diff hard to read after moving a block of text?

Because a line-based comparison has no concept of a move — it reports the block as deleted in one place and added in another. Some tools detect moves specially, but the underlying algorithm finds common subsequences rather than relocations.

🔒 This tool runs entirely in your browser. Nothing you enter is uploaded, logged, or stored.