Text Compare

A text compare tool takes two blocks of plain text, aligns them line by line, and highlights every line that was added, removed, or changed between the two versions. It is a line-based diff in its default mode, with an optional word-level view that drills into the exact tokens that shifted inside an edited line. The output is the same kind of patch you see in a version-control review screen, only stripped of repository plumbing and rendered straight from two textareas.

Writers, editors, support engineers, and developers reach for a text compare tool whenever two near-identical documents disagree. Typical inputs are a draft and its revision, a config file before and after a deploy, a contract redline, an email reply that quietly changed a clause, or two log snippets pulled from different runs.

Why use Text Compare?

• Spot edits in long documents. Line-by-line highlighting surfaces the one paragraph that changed inside a fifty-page contract or policy without forcing you to read both copies in full.
• Audit config drift between environments. Paste a staging config on the left and production on the right to see exactly which keys, hostnames, or feature flags differ before you ship a change.
• Review prose without a Git repository. Editors and content reviewers can run a clean diff on copy-deck revisions, blog drafts, or release notes that never lived in version control.
• Debug log differences across runs. Compare two captured log slices to isolate the timestamp, status code, or stack frame that only appears when the bug reproduces.
• Stay private with sensitive text. The diff runs entirely in your browser, so legal text, customer messages, and internal documents are never uploaded or stored on a server.

How to use Text Compare

1. Paste the first version into the Original textarea on the left.
2. Paste the second version into the Modified textarea on the right.
3. Leave the view in Line mode for a row-by-row patch, or click Word mode to highlight changes within a line.
4. Scroll the Diff panel below to read added lines in green, removed lines in red, and changed lines in amber.
5. Select any row and copy the highlighted text straight into a pull request comment, an email reply, or a bug report.

A minimal example, using line mode:

- The deploy script reads config from /etc/app/prod.yaml.
+ The deploy script reads config from /etc/app/prod.toml.
  Run it as the deploy user.

Diff algorithm

Under the hood the text compare tool uses a longest common subsequence (LCS) algorithm, the same family used by diff, git diff, and most code review tools. LCS finds the longest sequence of lines that appears in both inputs in the same order, treats those as unchanged, and marks everything else as added, removed, or changed.

In line mode, the unit of comparison is one line ending at \n. The algorithm pairs each line in the original with its counterpart in the modified version. When a line has a near match on the other side, the row is marked changed and rendered in amber rather than as a paired removal and addition. Word mode runs the same LCS pass at the token level, splitting on whitespace and punctuation so single-word edits inside a long sentence are visible without re-reading the whole paragraph.

The Myers diff algorithm, which underpins git diff, is a specific O(ND) implementation of LCS. The behavior you see here matches what a Git reviewer would see for the same two snippets.

Visual conventions

The diff panel uses one color and one prefix per change type, so a printed or screenshot diff is readable without the color cues.

The same convention applies in word mode, where the prefix is dropped and the change is shown inline with a strikethrough on removed tokens and a colored background on added ones.

Example diff

Two near-identical paragraphs, run in line mode:

- Refunds are processed within 5 business days of the request.
+ Refunds are processed within 7 business days of the request.
  Contact support@example.com for status updates.
- A 2% processing fee applies to card refunds.
+ A 1.5% processing fee applies to card refunds.

The same input in word mode would show 5 struck through and 7 highlighted in green inside the first line, and 2% struck through and 1.5% highlighted inside the last line, leaving the surrounding wording untouched.

Common use cases

• Editors reviewing copy revisions. Diff two versions of a landing page or email draft to confirm only the approved tracked changes made it into the final.
• DevOps engineers comparing environment configs. Spot the one Helm value, env var, or Nginx directive that differs between staging and production before a release.
• Support engineers diffing error logs. Paste a working session and a failing session side by side to isolate the request, status code, or timestamp that triggers the regression.
• Legal and ops teams redlining contracts. Read the actual changes inside an NDA or MSA when the counterparty sends back an untracked Word document.
• QA testers comparing API responses as text. When the payload is plain text or CSV rather than JSON, the line diff is enough to find the broken row.

Frequently asked questions

Is the text compare case-sensitive?

Yes. The diff treats Error and error as different strings, so a casing change is reported as a changed line. There is no global case-insensitive toggle, because most real diffs (logs, configs, code, contracts) treat case as meaningful. Lowercase both inputs before pasting if you only care about content.

Does it ignore whitespace?

Whitespace inside a line is preserved, so two lines that differ only by trailing spaces are flagged as changed. Leading indentation is also significant. This matches the default behavior of git diff; the equivalent of --ignore-all-space is not exposed in the UI.

Can I compare two files?

The tool reads from two textareas, not file uploads. Open each file in a text editor, press Ctrl/⌘ + A to select all, paste into the matching pane, and the diff runs as you type. For very large files, prefer diff on the command line.

Are my inputs uploaded anywhere?

No. The text compare tool runs entirely in the browser. Both inputs stay in memory in your tab and are never transmitted to a server, written to disk, or logged. Closing the tab clears them.

What is the maximum input size?

Practical limits depend on your browser and device. A few hundred kilobytes per side renders smoothly. Files in the multi-megabyte range can slow the tab because every diff row is rendered into the DOM. For very large comparisons, narrow each side to the section you actually need to inspect.

What is the difference between line mode and word mode?

Line mode pairs whole lines and is the right view for code, configs, and logs. Word mode pairs whitespace-separated tokens inside the matched region and is the right view for prose, where a one-word edit inside a long paragraph would otherwise show as a wholesale line replacement.

Why does a single inserted line shift the whole diff?

The LCS algorithm aligns lines by content, so when one line is inserted near the top, the lines that follow stay matched as unchanged. If you see a long run of paired removals and additions, the inputs probably diverged in structure (different line endings, an inserted blank line, or a column shift) rather than a few real edits.

Does it handle different line endings?

Yes. Windows-style \r\n and Unix \n line endings are both treated as line terminators. If one side uses one convention and the other uses the other, the diff still aligns correctly, though trailing \r characters may appear inside changed rows on mixed inputs.

Related tools

• Code Compare - Side-by-side diff of two code snippets with monospaced rendering.
• String Diff - Character-level diff of two short strings.
• XML Compare - Compare two XML documents line by line.
• JSON Compare - Deep-compare two JSON objects with a structured diff view.