Text Compare (Diff Checker)

Find what changed between two texts, line by line and character by character

The text comparator lines up an original and a revised version, then labels each line. A line that exists only in the revised text is added, a line that exists only in the original is deleted, and a line that has a counterpart on both sides but reads differently is modified. Inside a modified line it compares again by character or by word, so if "Monday, October 27" became "Tuesday, October 28", only the parts that really changed ("Mon" and "Tues", "7" and "8") are highlighted.

The workspace above opens with the meeting-notice example already loaded: 3 modified lines, 1 added, 1 deleted and a similarity of 75.1%. Clear both boxes and paste your own text, and the comparison updates as you type. Text and files are processed only inside this browser.

When a text comparison helps

Reading two versions back and forth by eye makes it easy to miss a change of a few characters, and that is exactly the kind of change that matters when a single number or a single "not" flips the meaning. A mechanical comparison is faster and more reliable.

• Reviewing an edit of your manuscript: An editor's pass, a spell-checker's output or a paragraph smoothed by an AI tool can all hide small unrequested changes. Comparing shows how much moved and where, including edits you never asked for.
• Receiving a revised contract, policy or terms of service: The dangerous clauses are the ones where only a figure shifted: a term, a fee, a notice period. With character highlighting, even "2027" turning into "2028" stands out.
• Re-sending an announcement or press release: Before you send the corrected version, collect just the changed lines into a short change note, or explain to recipients exactly what differs from the earlier message.
• Checking translations, subtitles and exported lists: Compare two translations of one source, two versions of a subtitle file, or two exports of the same list to find missing or extra lines.
• Comparing config files and code snippets: Get a diff of two versions on a machine with no developer tools. Lines that differ only in indentation can be filtered out with Ignore whitespace.

How to use it

1. Paste the earlier text into the Original box and the edited text into the Revised box. The File button on each box opens a text file or a DOCX, and you can also drop a file onto a box.
2. The summary and the result update as soon as you type. If you pasted them in the wrong order, the ⇄ button between the boxes swaps the original and the revised text.
3. Turn on Ignore whitespace to disregard spacing and indentation, or Ignore case to disregard upper and lower case.
4. In the result, choose Side by side or Unified, and highlight by Characters or Words. For a long text, switch on Changes only and step through the changes with the arrow buttons, or click a mark on the change map at the right edge.
5. To keep the result, press Copy diff or Save. Use Full screen for a wider view.

Reading the result

In the side-by-side view the original is on the left and the revised text on the right, and a modified line sits across from its counterpart on the same row. In the unified view the changed line (+) follows directly under the line it replaces (−). Line numbers are the real line numbers of each document.

The similarity ring in the summary shows how much of the two texts matches character for character, and the bar shows the share of same, modified, deleted and added lines. The narrow strip beside the result is the change map: it marks where changes fall across the whole height of the document, so in a long text you can see at a glance where they cluster and click to jump there.

Example results

The three example buttons in the workspace produce exactly the results below. The counts are the number of lines in each category, not the number of rows on screen, and similarity is rounded down at the first decimal place.

The config example shows how much the result depends on the options even when the text is the same. Compare a file whose indentation rule changed as is, and nearly every line comes out modified, burying the values that actually changed.

When to use Ignore whitespace and Ignore case

Ignore whitespace removes every space, tab and full-width space inside a line before comparing. Ignore case folds letters to lower case before comparing. Neither option touches line breaks, so a line that was split or joined still shows up as a difference. In the table, · stands for one space.

If you are proofreading spacing itself, leave Ignore whitespace off. When you review values where case matters, such as passwords, file paths or variable names, keep Ignore case off too. Line-ending characters (CRLF on Windows, LF on macOS and Linux) and the presence of a final line break are treated as equal whatever the options say; if that is the only difference, the status line says so.

How the tool finds differences

Aligning lines: The two texts become lists of lines, and the tool keeps the order while choosing as many identical lines on both sides as possible. That is the longest common subsequence (LCS) problem, which is the same as finding the fewest line deletions and insertions that turn the original into the revision. The tool solves it with the O(ND) algorithm Eugene W. Myers published in 1986. N is the combined number of lines and D is the number of deletions and insertions needed, so the fewer the edits, the faster it finishes, and because it splits the path at the midpoint it uses little memory even on large documents. It is also the default algorithm of git diff.

Pairing modified lines: Where a block of deleted lines and a block of added lines sit between two identical lines, the tool measures how alike each pair is by how many two-character fragments they share. It first picks the pairs with the greatest total similarity while keeping the order, then pairs the remaining lines from the top and treats each pair as a modification. So even if you insert a new sentence just before an edited line, the new sentence stays an addition and the edited line stays a modification.

Comparing inside a line: Each paired line is split again into characters or words and compared with the same algorithm. Characters are Unicode grapheme clusters, so an emoji or a combined accent is never cut in half, and words follow the browser's word-boundary rules, which also split Japanese that has no spaces. Short unchanged fragments caught between changes are then merged into the change so it reads in human-sized chunks such as "brown → red". That cleanup follows the rules of the semantic cleanup (cleanupSemantic) in Google's diff-match-patch.

Similarity: Let S be the number of characters matched in the same position within the same lines and the modified lines, and A and B the character counts of the original and the revision. Similarity = 2 × S ÷ (A + B). Line breaks are not counted, and with Ignore whitespace on, spaces are left out as well. It shows 100% only when the texts are completely identical; any difference, however small, is rounded down so it never reaches 100%.

Reading the copied or saved diff

Copy diff and Save produce GNU diff's unified format (diff -u). Copying the notice example above gives the text below. Each change carries three lines of unchanged context before and after, and changes six or fewer lines apart are merged into one hunk.

--- Original
+++ Revised
@@ -1,7 +1,7 @@
 [Notice] October Regular Meeting
-The meeting is on Monday, October 27 at 2 PM in the 3rd-floor meeting room.
+The meeting is on Tuesday, October 28 at 3 PM in the 3rd-floor conference hall.
 The agenda is the second-half budget review and the new project schedule.
-Bring: laptop, last quarter's report
-If you cannot attend, please reply by Friday.
-Minutes will be shared the day after the meeting.
+To join by video, please use the meeting link.
+Bring: laptop
+If you cannot attend, please reply by Thursday.
 Thank you.
\ No newline at end of file

• The --- and +++ lines are the names of the original and the revision. If you opened files, their file names appear here.
• @@ -1,7 +1,7 @@ means this hunk covers 7 lines starting at line 1 of the original and 7 lines starting at line 1 of the revision. A one-line hunk gives only the line number, such as -5, and an empty side gives the line before it and 0, such as +0,0.
• A minus (-) at the start of a line marks a line only in the original, a plus (+) marks a line only in the revision, and a line starting with a space is the same on both sides. Inside a hunk, all the original lines come first and then the revised ones.
• Applying it to the original with the patch command (patch original.txt < saved.diff) gives the revised text, and code-review tools and email clients display it well. Each line keeps its own line ending (CRLF or LF), and if the last line has no line break, a \ No newline at end of file line follows it. A diff made with Ignore whitespace or Ignore case does not contain those differences, so turn both options off when you need a diff to apply.

Files and encodings

Text files up to 2 MB and DOCX files up to 20 MB open. The extension does not matter: any file whose content is text, whether TXT, MD, CSV, JSON, HTML, SRT or a log, is read. If a zero byte appears near the start, the file is treated as binary, like an image or a program, and is not read.

• Detecting the encoding: With a byte order mark (BOM) at the start, the file is read as UTF-8 or UTF-16 as marked. Without one, the tool tries UTF-8 first. If that does not fit, it tries EUC-KR (including Windows' CP949), Shift_JIS and Windows-1252, picks the one that gives natural-looking Korean, kana or Latin letters, and shows the chosen encoding above the box. An older Windows file saved as "ANSI" in Notepad, which is usually Windows-1252 for Western European text, is the typical case.
• DOCX: The body inside the zipped DOCX (word/document.xml) is read with one paragraph per line. A table gives one line per cell, and text boxes are included in body order. If tracked changes are left in the file, inserted text is kept and deleted text is dropped, so you get the body with every change accepted. Headers, footers, footnotes, comments and formatting such as fonts and colors are not compared.
• Formats that are not read: HWP and HWPX (the Korean word processor's files), PDF, DOC, Excel, PowerPoint and image files are not read directly. Select the whole body in the program, copy it and paste it here. Text copied from a PDF may be broken at the end of every page, so copy both sides the same way for an accurate result.

Common mistakes

• Putting the original and the revision the wrong way round: Additions and deletions then look swapped. Check that the earlier text is in A and the newer one in B, and press ⇄ if not.
• Pasting a text that was wrapped on only one side: Text copied from an email or a PDF is broken at the screen width, which can make every line differ. Copy both texts from the same place in the same way.
• Reading similarity as a plagiarism score: Similarity is only the share of characters that remain in the same order. It says nothing about sources or quotations, and a passage copied sentence by sentence but reordered can score low.
• Applying a diff made with an ignore option on: A diff made with Ignore whitespace leaves out indentation changes. Turn the options off before making a diff to apply to a file.
• Missing invisible characters: Text copied from the web can hold zero-width or no-break spaces, so two lines look the same but are reported as different. A box like 200B or a ⍽ symbol at the changed spot is the culprit.

Limits and cautions

• Each document can be up to 500,000 characters and 20,000 lines. Split anything longer by chapter or page. When a result exceeds 1,000 lines, the result opens with Changes only on.
• If the two texts are mostly different, line alignment has a time limit of 1 second. Past it, the tool stops looking for identical lines in the remaining stretch, pairs those lines in order as modified, added or deleted, and says so in the status line, so the number of modified lines can be higher than the real one. The result shows up to 3,000 lines at a time; a button at the bottom opens the rest.
• Moved paragraphs are not tracked separately and appear as a deletion plus an addition. In a text that repeats the same sentence many times, several alignments are possible, so the pairing may differ from the one a person would choose.
• Only characters are compared. The tool does not judge whether two different wordings mean the same, whether spelling is right, or anything about formatting, fonts and images.
• Input and results are not stored, so closing the page discards them. If a result contains personal data, check it again before copying and sharing it.

Sources

As of The documents below were checked against the originals on October 22, 2026. The journal details of Myers' paper were confirmed from the Crossref record. The line counts, similarities and diff example in this article are this tool's own output. For the diff format, 120 random document pairs were applied to the original with the patch command to confirm the result equals the revision, and the empty-range notation (-0,0) was checked against the output of the diff command.

• 01Eugene W. Myers — An O(ND) Difference Algorithm and Its VariationsAlgorithmica vol. 1, pp. 251-266 (November 1986, DOI 10.1007/BF01840446). The longest common subsequence and the shortest edit script are the same problem; the linear-space refinement
• 02J. W. Hunt, M. D. McIlroy — An Algorithm for Differential File ComparisonBell Laboratories Computing Science Technical Report #41 (July 1976)
• 03GNU Diffutils Manual — Unified FormatThe -u option and the default of three context lines
• 04GNU Diffutils Manual — Detailed Description of Unified FormatThe --- and +++ header, the @@ hunk header (a one-line hunk gives only the start line number), and the meaning of a leading space, - and +
• 05Git documentation — git-diff--diff-algorithm (default myers), --word-diff
• 06Google diff-match-patch — APIdiff_cleanupSemantic: tidying changes into human-readable chunks
• 07Unicode — UAX #29 Unicode Text SegmentationGrapheme clusters and word boundaries
• 08WHATWG — Encoding StandardEUC-KR covering Windows code page 949 (extended Wansung), and how Shift_JIS and windows-1252 are interpreted
• 09Ecma International — ECMA-376 Office Open XMLDOCX body structure (paragraph w:p, text w:t, tracked changes w:ins and w:del)
• 10MDN — DecompressionStreamUnpacking deflate-raw data inside the browser

Frequently asked questions

Tools to use with it