Lite Tools

Diff Checker

Compare two texts online line by line, highlighting additions, deletions and modifications in different colors. The longest-common-subsequence (LCS) algorithm runs locally in your browser: ideal for code, config and document comparison.

0 lines
0 lines

How to use

  1. Paste the original text into the left box and the modified text into the right box; each line is treated as one comparison unit.
  2. Click "Compare" to diff the texts line by line, or tick "Live compare" to re-run the diff automatically whenever either side changes.
  3. In the result, unchanged lines are muted, added lines are green, removed lines are red with a strikethrough, and replaced (changed) lines are highlighted in yellow.
  4. The summary above the result totals the added, removed and changed lines, so you can gauge the scale of the changes at a glance.
  5. For JSON or source code, remove trailing whitespace differences or format both sides first for a cleaner result.

FAQ

Which algorithm does this use and how accurate is it?
The tool implements a line-level longest-common-subsequence (LCS) diff itself: no third-party libraries and nothing uploaded. It finds the common lines that stay unchanged between the two texts and classifies the rest as additions, deletions or replacements.
What is the difference between "changed" and "removed + added"?
When a run of old lines is replaced by a run of new lines of the same length, the new lines are shown as changed (yellow). When only one side gains or loses lines, they are reported as additions or removals, keeping the summary intuitive.
How do the lines map back to the original texts?
The diff keeps the original order: unchanged lines stay in place, removed lines appear at their original position, and added lines are inserted with a + marker next to the matching context, so you can compare against both panels.
Will huge or completely different inputs freeze the page?
The algorithm is optimized for typical sizes. If an input has too many lines (several thousand per side), the tool falls back to a simpler line-aligned mode and says so: it still completes entirely in your browser.

How to use

  1. Load both versions

    Paste the original text into the left pane and the modified text into the right one. Each pane shows a live line count, since the comparison works line by line.

  2. Run the comparison

    Click Compare to diff the two texts with an LCS algorithm. Unchanged lines stay muted, additions turn green, deletions show red with strikethrough, and replacements appear in yellow.

  3. Enable live compare

    Tick Live compare to recompute automatically while you type on either side. This suits short texts and quick edits when you are changing one version by hand.

  4. Check the summary chips

    Read the Difference summary above the result: it totals added, removed and changed lines. That gives an immediate sense of how large a revision is.

  5. Normalize before diffing

    For JSON or source code, format both sides to the same indentation and strip trailing whitespace first. The result then highlights real changes instead of formatting noise.

About this tool

This diff checker compares two texts line by line using a longest-common-subsequence algorithm implemented from scratch, without third-party libraries. It identifies the lines both versions share, then classifies the rest as added, removed or changed. Each category gets its own color and a summary count. Because the whole computation runs locally, comparing proprietary code, licenses or customer data never exposes a single line to a server.

Use it to see which parameters changed between two config files, or to review which lines a teammate or your own patch touched. It also proofreads two versions of a contract or article. Before a release, use it as a sanity check: export the generated output, diff it against last time, and confirm nothing unexpected moved. Writers, reviewers and operations engineers can read the same line-level differences as developers.

How it works

The mathematical core of line diffing is the longest common subsequence. Treat both texts as sequences of lines, fill a table with dynamic programming, and pick the alignment that keeps the most lines. Everything left over becomes an addition or a deletion. The table's size is the product of the two line counts, so a thousand lines against a thousand lines is a million cells. Time and memory both scale with that product. GNU diff and early git use Eugene Myers's 1986 O(ND) algorithm, which minimizes the same edit distance. It is mathematically dual to LCS.

Minimal edit scripts are rarely unique. Shifting a paragraph down one line can be read as a move or as a deletion plus an addition, so tools may disagree about classification. Line-level comparison also has a blind spot. One changed character marks the whole line as removed and added, hiding which word moved. Word-level diff in editors and git exists for exactly this. Files with many repeated lines, such as stacked imports, can pull the alignment off target. Git offers patience diff for this, anchoring on lines that appear only once.

When to use it

  1. Comparing API response snapshots

    Save one response before and one after an API upgrade, format both to the same indentation, and diff. New and vanished fields stand out at once, and the result drops neatly into a regression report.

  2. Hunting environment config drift

    Paste the exported configs from production and staging side by side. Read the totals first, then walk line by line, prioritizing yellow replacement rows. Rewritten lines usually matter more than pure adds or deletes, and silently adjusted timeout thresholds live there.

  3. Proofreading batch-generated text

    Templated emails, SQL or scripts generated in bulk can differ in scattered rows because of data variation. Diffing the whole batch surfaces outliers, and a summary count that misses the expected total exposes missing or duplicated output.

Tips & tricks

  • Changed means an equal-length replacement: a run of old lines covered by the same number of new lines. Otherwise the same edit counts as removed lines plus added lines.
  • For inputs of several thousand lines per side, the tool falls back to a simpler line-aligned mode and says so. Very large files still finish entirely in the browser.
  • Strip trailing spaces and normalize line endings before comparing; most noisy diffs come from invisible whitespace rather than from real content changes.

Things to watch

  • A one-character change marks the whole line

    Line diffs only know whole lines. Changing one character shows as a deleted line plus an added one, which reads like a large change. To see what actually moved, isolate the line and compare word by word, or use an editor's inline diff.

  • Encoding mismatch fakes a full rewrite

    Diff a UTF-8 file against a GBK one and every line of Chinese text is reported as changed. The result is a wall of red unrelated to content. Normalize encodings first; only then does the comparison mean anything.

  • Single-line files hide the location

    Minified JSON or an unbroken paragraph is one single line. A line diff can only report the entire line as different, without saying where. Format or wrap the content into many lines first, and the difference will land in a specific spot.

Related Tools