Text Diff Comparator

Introduction:

Text changes are easy to underestimate when two versions look almost the same. A revised checklist might add one operational step. A configuration note might change a timeout value. A policy paragraph might remove a required condition while leaving the surrounding wording intact. Line-by-line comparison gives those edits a visible shape before the revised text is copied, reviewed, merged, or sent onward.

A diff is most useful when it separates the kinds of change instead of treating every mismatch as one vague difference. Added lines, removed lines, replaced lines, unchanged context, and matches produced by ignore rules all mean different things during review. Formatting noise can hide the real edit, but aggressive ignore settings can also hide a change that matters in code, Markdown, CSV data, shell snippets, environment variables, and fixed-width text.

Unified diff notation is a compact way to carry the important parts of a change. Removed lines use a leading minus sign, added lines use a leading plus sign, and unchanged context lines keep nearby text visible so a reviewer can see where the edit happened. A hunk is one grouped area of nearby edits plus the surrounding context.

Line diffs are not proof of intent. A moved paragraph can appear as a deletion plus an addition. A case-only edit can vanish if case is ignored. A blank line may be harmless in prose and significant in a patch, configuration file, or Markdown list. Good review starts with exact comparison, then narrows the noise only when the review purpose makes that safe.

How to Use This Tool:

Begin with the exact text on both sides, then use the advanced comparison options only when you have decided which differences are safe to ignore.

1. Paste the baseline into Original text, or choose Browse original to load a TXT, MD, CSV, JSON, LOG, DIFF, or PATCH-style text file. The file must be under 2 MB.
2. Paste or load the candidate version in Revised text. The summary changes from Add text to original and revised line counts, plus badges for changed, added, removed, equal, and ignored rows.
3. Use Load sample when you want a quick known comparison before pasting private or project-specific text.
4. Open Advanced only after the first pass. Trim line edges, Collapse whitespace, Ignore case, and Ignore blank lines change the matching rules, while Context lines controls the amount of unchanged text shown around each unified diff hunk.
5. Read Unified Diff for the compact review artifact. Use Change Ledger for non-equal rows, Pair Review for every aligned row, and Match Audit for counts, options, hunks, and warnings.
6. Check Diff Change Mix Chart when the review has many rows and you need a quick sense of whether the change set is mostly replacements, additions, removals, ignored matches, or exact matches.
7. If a file is rejected, use one of the accepted text-like formats, reduce the file below 2 MB, or paste a smaller extract directly into the textarea.

Before copying a diff, table, chart, or JSON result, confirm that Comparison options in Match Audit matches the rules you intended for the review.

Interpreting Results:

Material changes is the first number to read. It adds changed, added, and removed line rows after the active comparison options have been applied. No material changes means those three row types are zero under the current settings, not that the two text blocks are byte-for-byte identical.

• Changed means one original line and one revised line were paired as a replacement.
• Added means the revised text contains a line that has no matching original line.
• Removed means the original text contains a line that has no matching revised line.
• Equal means the visible line text matched exactly.
• Ignored means visible text differed, but the active options made the comparison keys match.

Use Changed line pairs, Added lines, and Removed lines to judge the size of the review. Use Unified diff hunks to see whether the edits are clustered or spread out. Use Ignored option matches as a warning count, especially when whitespace, case, or blank lines can change behavior.

A unified diff is a review artifact, not a guarantee that a patch will apply to a target file. File paths, exact surrounding content, line endings, and any edits made after the comparison can still affect patch application elsewhere.

Technical Details:

Line-oriented comparison treats each text block as an ordered sequence of lines. End-of-line styles are normalized before splitting, so pasted Windows, Unix, and older carriage-return line endings can be compared in the same review. Blank-only lines remain part of the sequence unless the blank-line option removes them before matching.

The core problem is to find a short edit path from the original sequence to the revised sequence. Equal positions become context rows. Insertions become added rows. Deletions become removed rows. A neighboring deletion and insertion can be paired as a changed row when that makes the review easier to read, but the unified diff still represents the replacement as one removed line followed by one added line.

Transformation Core:

Formula Core:

The headline count is intentionally narrow. It counts only the rows that still represent material edits after the active matching rules have done their work.

Equal and Ignored rows are excluded from the material total. Ignored rows still deserve attention because they show places where the visible original and revised text differed before normalization.

Option Effects:

Changed row notes are based on token comparison inside the paired lines. Whitespace runs and non-whitespace runs are compared as tokens, so a replacement can show how many tokens were added or removed. Very long paired lines switch to a character-count note instead of a token summary after the combined token count becomes too large for a useful inline note.

The unified output uses --- Original and +++ Revised headers, followed by hunk headers in the form @@ -oldStart,oldCount +newStart,newCount @@. Those ranges describe the old and new line spans included in each displayed hunk, not the whole document.

Privacy and Limits:

The comparison runs in the browser after the page loads. Pasted text and accepted local file content are read there to build the summary, diff, tables, chart counts, and JSON output.

• Supported file loading is limited to text-like TXT, MD, CSV, JSON, LOG, DIFF, and PATCH files under 2 MB.
• Line comparison is not syntax-aware. It does not parse JSON, CSV, Markdown, code, or configuration semantics.
• Moved blocks are not detected as moves. They usually appear as removals and additions.
• Exact patch application depends on the destination file and patch tooling, not only on the displayed hunk text.

Worked Examples:

Release checklist update. The sample original has six lines and the revised text has seven. Exact comparison reports 3 changes: two changed line pairs for the smoke-test and notification wording, plus one added line for launch metrics. Unified diff hunks groups those nearby edits into one hunk with surrounding checklist context.

Whitespace and case cleanup. If Status: Ready becomes status: ready , exact matching reports a changed row. Turning on Trim line edges, Collapse whitespace, and Ignore case can reduce Material changes to zero, while Ignored option matches shows that the visible text was not identical.

Blank-line review. A Markdown list may rely on blank lines to separate paragraphs from list items. With Ignore blank lines off, an added empty line can appear as an added row. With the option on, Original lines compared and Revised lines compared can be lower than the raw line counts, and that blank-line edit will no longer appear in aligned rows.

Rejected file during review. Dropping a PDF, image, or 3 MB log export into a textarea does not replace the text. The status message asks for a supported text-like file under 2 MB. Use a text extract, then confirm that Original lines compared and Revised lines compared are nonzero before relying on the result.

FAQ:

Advanced Tips:

• Run an exact comparison first, then enable Trim line edges, Collapse whitespace, Ignore case, or Ignore blank lines only when those differences are irrelevant to the review.
• Use Ignored option matches as a warning count. A zero material-change result can still hide visible text changes after normalization.
• Set Context lines to 0 for compact review notes, 3 for ordinary patch-style context, and a higher value when repeated blocks make a hunk hard to place.
• When large inputs trigger line-count or table-size warnings, narrow the pasted extract before relying on Pair Review. CSV or JSON exports are easier to inspect than a very long table.
• Use Change Ledger for changed, added, removed, and ignored rows, Pair Review for every aligned row, and Match Audit to prove which options and warnings applied.
• Test copied unified diff text with the target patch tool when application matters. The displayed hunk text does not verify file paths, line endings, or later edits in the destination file.

Glossary:

Unified diff

A compact text diff format that marks removed lines with -, added lines with +, and context lines with a leading space.

Hunk

A grouped area of nearby changes plus the selected unchanged context lines around them.

Edit path

The sequence of equal, inserted, and deleted steps that transforms the original line sequence into the revised sequence.

Comparison key

The line value used for matching after any active trim, whitespace, case, or blank-line rule has been applied.

Ignored match

A row that matched after active ignore options even though the visible original and revised text differed.

References:

• Unified Format, GNU Diffutils Manual, version 3.12, 12 January 2025.
• git-diff Documentation, Git project, version 2.54.0, 20 April 2026.
• An O(ND) Difference Algorithm and Its Variations, Eugene W. Myers, Algorithmica, 1986.