Text Diff

Line-by-line and word-level text diff with syntax highlighting, whitespace-ignoring, split and unified views, and patch export. Free, no upload, runs in your browser.

How to use the Text Diff

  1. Paste or type the original text into the "Original Text" panel, or click "Open file" to load one.
  2. Paste or type the updated text into the "Changed Text" panel.
  3. Pick a language from the row of buttons (Auto, JS, TS, Python, JSON, XML, YAML, CSS, HTML, SQL, Text) for syntax highlighting — it auto-detects from the file extension when you open a file.
  4. Click "Find Difference" to render the diff.

The diff viewer supports ignoring whitespace/case, collapsing unchanged context, and exporting the result as a .patch file — look for those controls inside the diff view itself.

About the Text Diff

Comparing two versions of a file is the most common thing a developer does that is not writing code. Which lines did that refactor touch? What did the vendor change in the config they sent back? Why does this generated file differ from the one in the repository?

This is a line-oriented diff with word-level highlighting inside changed lines, syntax highlighting for common languages, and the options that make a diff readable in practice — ignoring whitespace, collapsing unchanged context, and exporting the result as a patch file.

When you'd use it

  • Comparing two versions of a config file, log, or SQL script.
  • Checking what changed in a generated file — a lockfile, a build artifact, an exported schema.
  • Reviewing a snippet someone pasted into a ticket against the version in your working copy.
  • Diffing two error stack traces to find where the execution paths diverged.
  • Producing a .patch file from two files that were never in version control together.

Word-level highlighting inside a changed line

When a line changes, a line-level diff tells you only that. Word-level highlighting narrows it to the token that actually moved.

Original

const timeout = setTimeout(retry, 3000)

Changed

const timeout = setTimeout(retry, 15000)

Ignore whitespace, and when not to

Whitespace-only changes dominate diffs after a reformat, an editor with different indentation settings, or a file that picked up Windows line endings. Turning on ignore-whitespace suppresses those and leaves the substantive changes.

There are cases where you must leave it off. Python and YAML take meaning from indentation, so an indentation change is a real change. Markdown treats trailing double spaces as a line break. Makefiles require literal tabs. In any of those, a whitespace-only diff is exactly the diff you are looking for.

Line endings

A file written on Windows ends its lines with a carriage return and a line feed; one written on macOS or Linux uses a line feed alone. The invisible carriage return makes every single line differ, which is why a file that looks identical sometimes diffs as 100% changed.

Ignore-whitespace normalises this. If you are seeing a total diff on files that appear the same, this is almost always the cause.

Split view versus unified view

Split view puts the two versions in parallel columns. It is easier to read when lines were modified in place, because your eye can compare across at the same vertical position.

Unified view interleaves them into one column with + and - markers, the format git and patch files use. It is easier to read when content moved a long distance, and it is what you want if you are going to copy the output into a pull request comment or an email.

Exporting a patch

The export produces a unified diff in the standard format, which git apply and the patch utility both accept. This is the practical way to move a change between two copies of a file that share no version control history — for example, applying a fix a contractor sent as a whole file back onto your branch as a reviewable change.

Frequently asked questions

Does it detect the language automatically?
It infers the language from the file extension when you open a file, and you can override it with the language buttons. Highlighting is cosmetic — it affects readability, not what counts as a difference.
The whole file shows as changed. Why?
Almost always mixed line endings. Enable ignore-whitespace to confirm; if the diff collapses to a handful of lines, that was it. Indentation changed from tabs to spaces produces the same symptom.
Is there a size limit?
Files of a few megabytes are fine. The diff algorithm is quadratic in the worst case, so two very large files with few lines in common can take a noticeable moment. Collapsing unchanged context helps with rendering, not with the comparison itself.
Should I use this for JSON?
Only if you care about the literal text. For comparing what the data says, JSON Diff parses both sides and ignores formatting and key order, which is nearly always what you actually want.
Are my files uploaded?
No. Files are read with the browser FileReader API and diffed in the tab. Nothing is transmitted.

Related tools