Text Diff Checker compares two text versions line by line in your browser and labels every row as added, deleted, or unchanged using a deterministic longest-common-subsequence algorithm. To do the same task Notepad++ users normally perform with the Compare plugin, paste the original text on the left, paste the changed text on the right, and select Compare lines. The tool then returns a single ordered list where additions begin with a plus sign, deletions begin with a minus sign, and unchanged rows carry a neutral prefix. A summary at the top reports added, deleted, and unchanged line counts, both texts stay inside the browser tab and are never uploaded, and the result is reproducible: the same inputs always produce the same rows. Each side is bounded at 500 lines or 200,000 UTF-16 code units, whichever is hit first, and an over-limit side is rejected before any comparison runs, so nothing is silently truncated. Empty input on either side counts as zero lines, and the comparison stays local even when both texts run into tens of thousands of characters.
Why Notepad++ users reach for a browser-side diff
Notepad++ handles text differences through its Compare plugin, which marks added, deleted, and changed lines in side-by-side buffers with color highlighting. The plugin is installed through Plugins → Plugins Admin and invoked from the Plugins menu, so it stays inside the Notepad++ process. That workflow works well when both files are already open in Notepad++ and the plugin is permitted to load, but several situations push users toward a browser-side method instead.
Plugin installation may be blocked on a managed machine, or the text you want to compare may live in the clipboard rather than as a saved document. Sometimes the goal is to share a quick visual diff with a colleague who does not have Notepad++ installed, or to review two prose versions where color highlighting on a single-line change is harder to scan than a clean plus or minus list. A browser tool also sidesteps the encoding-mismatch trap that sometimes appears when one buffer is UTF-8 and the other is Windows-1252, because the pasted text is treated as the literal characters shown on screen rather than re-decoded from a file on disk. For these cases, Text Diff Checker gives the same plus or minus view that Notepad++ users expect, without a plugin install or an extra process.
Run a line-by-line comparison
- Paste the original text in the left panel and the changed text in the right panel.
- Select Compare lines.
- Review plus additions, minus deletions, unchanged rows, and the summary counts at the top.
Each of those steps has a small amount of detail worth knowing before you click. The two panels accept pasted blocks. Paste the entire block at once so the line boundaries on each side stay aligned: a partial paste will compare against whatever happens to live on the other side, which is rarely the result you want. Once both sides are populated, select Compare lines. The button first checks size: if either side exceeds 500 lines or 200,000 UTF-16 code units, the comparison does not start. If the inputs pass the check, the longest-common-subsequence table is built and the result is rendered as a single ordered list. To compare a different pair, edit either side: editing clears the previous comparison as soon as the text changes, so the numbers you see always reflect the visible rows.
Reading the plus, minus, and neutral rows
The output is one ordered list rather than two side-by-side buffers. Each row carries a marker that tells you where the line came from: a plus sign for a line that appears only in the changed version, a minus sign for a line that appears only in the original, and a neutral marker for a line that matched in both. Above the list sits a summary that reports the count of added rows, the count of deleted rows, and the count of unchanged rows. The counts are derived from the same row types that are visible in the list, so the totals and the visual representation cannot drift out of sync.
| Marker | Meaning | Source panel |
|---|---|---|
| + plus | Line is present only in the changed text | Right |
| - minus | Line is present only in the original text | Left |
| neutral | Line matched exactly in both versions | Both |
Because the same line content can appear on both sides without being marked neutral, it helps to remember that "unchanged" here means the row was selected into the longest common subsequence by the algorithm. The summary counts and the visible prefixes always agree because both are computed from the same final row list.
What counts as an unchanged line
Line equality in this tool is exact string equality. That includes capitalization, every punctuation character, every leading space, every trailing space, every tab, and every Unicode code point inside the line. A one-character edit such as changing a comma to a semicolon, lowercasing a single letter, or appending one space will therefore appear as one deleted line and one added line, not as an in-place highlighted change. The comparison unit is the complete line, not the character or the word.
CRLF, standalone CR, and LF are all recognized as line boundaries. CRLF is treated as one boundary rather than two. The comparison normalizes boundary syntax for analysis while keeping the content inside each line exactly as pasted, so a Windows-saved original and a Unix-saved changed version will still match on identical content lines without flagging the line endings themselves as differences.
This coarse view is intentional. It stays understandable for lists, configuration snippets, prose paragraphs, and small code excerpts. If a single row shows a meaningful difference, the fix is on you to inspect the row contents side by side and apply the change in your real editor.
Empty inputs, blank lines, and duplicate lines
An entirely empty input on either side is treated as zero lines, and the tool will compare the non-empty side against an empty array: every line on the non-empty side appears as an addition or a deletion depending on which panel is empty. Empty lines inside a non-empty text are valid line values and participate in matching like any other line, so a blank line that exists in both versions shows up as unchanged, while a blank line that was inserted or removed shows up as a plus or minus row.
Duplicate lines can produce more than one valid optimal alignment, because the same identical line can be matched in several positions. The implementation uses a deterministic tie rule that favors an addition when the remaining subsequence lengths are equal, so the same inputs always yield the same rows. The view is an explanatory diff, not a patch generator: there are no line numbers, no character-level highlights, no whitespace or case folding, no moved-block detection, and no merge-conflict markers. If you need a unified-diff file you can apply with patch, this is not the right output.
Size limits and what happens when a side is too large
Each side is capped at 500 lines and 200,000 UTF-16 code units. Longest-common-subsequence comparison has quadratic work in line count, so the explicit cap keeps browser memory and latency bounded on a typical tab. Character limits also bound input storage and rendering. If either side exceeds the cap, the comparison does not start and nothing is silently truncated. The over-limit side is rejected before the dynamic-programming table is built, and you can shorten the input before retrying.
For texts that run past the cap, the practical options are to split the file into predictable chunks before pasting, or to use a streaming or native diff utility that does not need to hold both files in memory at once. Notepad++ users can prepare the chunks in the editor itself with a workflow like the one described in this Notepad++ split-by-line-count guide, then paste each chunk into the browser tool and read the partial diffs in order. Even when the inputs are large, all processing stays in the current tab, so neither version leaves the browser.
When a browser diff is the wrong tool
A displayed equality under this tool's rules means exact string equality under its documented matching, not semantic equivalence. Different Unicode normalization forms, visually similar characters, hidden tab or non-breaking-space characters, or line-ending conventions inside an escaped string can all surface as changes that look identical on screen. Inspect any change that affects a sensitive downstream format in that destination format, and keep the original versions available until review is complete.
For a source repository, Git tracks history, filenames, renames, patches, authorship, and conflict resolution in a way this view cannot. For very large files, a streaming or native diff utility is the right tool because pasting a multi-megabyte file into a browser will exceed the line or character cap. The output is an explanatory view rather than a file suitable for automated application, so do not feed it into a patch pipeline expecting unified-diff syntax.