Guides › Text, code, and data

How to compare two versions of a text and see what changed

Last updated 10 October 2026 · Written by Souren Das

Someone sends back "a few small edits" to a contract, a policy, or a config file, and you need to know exactly what changed. Reading both versions side by side is slow and you will miss things. A diff tool compares the two texts for you and marks every line that was added or removed. This guide explains how line comparison works, how to use Text Diff, and how to get useful results from prose as well as code.

When a diff helps

Checking what a colleague changed in a draft before you approve it.
Comparing two versions of a configuration file before you deploy one.
Seeing what changed between two exports of a list, such as two versions of a product catalogue.
Confirming that a long key, hash, or ID you were sent matches the one you expected.
Producing a patch file a developer can apply with git.

If both versions are Word documents and you have Word, its built-in Compare feature shows formatting changes too. A text diff only sees the words.

How line comparison works

Text Diff uses the jsdiff library, which finds the smallest set of added and removed lines that turns the old text into the new one. It works line by line. If one word in a line changes, that whole line is shown as removed from the old version and added in the new one. This is how git and most code review tools show changes, and it is very clear for code, lists, and anything with one item per line.

For prose, it means a long paragraph written as one line will show as one big change even if a single comma moved. The trick in the next section fixes that.

Step by step

Open Text Diff. It starts with two sample JSON snippets so you can see the result immediately.
Paste the older version into Original Text (Before) and the newer version into Modified Text (After).
Read the counters at the top: Added Lines, Removed Lines, Unchanged, the change in characters and words, and a match status that says Identical or Differences Found.
Scroll to the result. In Side-by-Side View, every line is listed in order in one column: removed lines are shaded red and marked with a minus, added lines are shaded green and marked with a plus, and unchanged lines are plain.
Switch to Unified Git Patch to see the same changes in the standard patch format, with @@ markers showing where each change sits.
Press Copy Unified Patch or Download .patch to share the result. The download is named filetoolskit-diff.patch.

If you pasted the versions the wrong way round, press Swap Panes.

Options that reduce noise

Ignore Whitespace treats lines that differ only in spaces or tabs as the same. Useful when someone re-indented code or an editor added trailing spaces.
Ignore Case treats upper and lower case as the same. Useful for lists of names or keywords typed inconsistently.

Both options only change how lines are compared. The text on screen keeps its original case and spacing. The patch is always built from the raw text, so it still includes whitespace and case changes.

Comparing prose: one sentence per line

For articles, policies, and letters, put each sentence on its own line in both versions before comparing. Most text editors can do this with find and replace: replace ". " (full stop and space) with a full stop and a line break. Then each changed sentence shows up on its own, and unchanged sentences stay unmarked. This turns a diff of a long paragraph from "everything changed" into "these two sentences changed".

If you are comparing text copied from PDFs, line breaks often fall in different places in the two copies. Join the lines into paragraphs first, then split by sentence.

Common problems

Every line shows as changed. The two texts likely use different line endings (Windows and Mac/Linux) or one has trailing spaces on every line. Turn on Ignore Whitespace. If that does not help, paste both through a plain text editor first.
A small edit shows as a big change. The text is one long line. Split it by sentence as above.
Moved paragraphs. A diff shows a moved block as removed in one place and added in another. That is expected; look for the same text in both.
Formatting changes are invisible. Bold, colours, and fonts are not part of plain text. Use your word processor's compare feature for those.
Very large files feel slow. Comparing tens of thousands of lines takes noticeably longer in a browser. Compare the relevant section only.

Reading a unified patch

A patch starts with two header lines naming the old and new files. Each block of changes starts with a line like @@ -3,4 +3,6 @@, which means "starting at line 3, four lines from the old file become six lines in the new one". Lines starting with - were removed, lines starting with + were added, and lines starting with a space are context. Developers can apply this file to the original with git apply or patch.

Privacy

Contracts and configs often hold confidential terms, passwords, or keys. Text Diff runs in your browser tab; the text is not sent to FileTools Kit and is not saved. Still, remove live passwords and keys before pasting them anywhere, and be careful on a shared screen.

FAQ

Does it highlight the exact word that changed?

No. Changes are shown per line. Split long lines into sentences to narrow it down.

Can I compare PDF or Word files directly?

No. Copy the text out and paste it in. To get text from a DOCX file, export it as TXT with File Converter.

Can I compare more than two versions?

Compare them in pairs: version 1 with 2, then 2 with 3.

Is the comparison order important?

Yes. Put the older text in Original Text (Before). Otherwise additions show as removals.

Written by Souren Das, FileTools Kit, Bengaluru. Last updated 10 October 2026. Spotted a mistake or a step that does not match the tool? Email support@filetoolskit.com and I will fix it. See how tools and guides are tested.