To check the difference between two text files, paste the original version on the left and the changed version on the right, run the comparison, and read a single ordered list where additions begin with a plus, deletions begin with a minus, and unchanged lines have a neutral prefix. The view shows whole lines rather than individual characters or words, so a one-character edit inside a line appears as one deletion paired with one addition. Both inputs are capped at 500 lines and 200,000 UTF-16 code units per side, and the entire process runs in the browser tab without uploading either version to a remote service. This kind of line-based comparison is well suited to short configuration files, prose drafts, log snippets, environment files, or small code excerpts where you want to confirm exactly which lines were added, removed, or left alone. For longer files, multi-file repositories, or version control across history, a native diff utility or a dedicated source-control system is the more appropriate tool.
How the Diff View Is Organized
The output of a comparison is a single column of rows, one per source line in original order. Each row carries a prefix that tells you what happened to that line when moving from the left text to the right text.
- Neutral prefix: the line is identical on both sides and is part of the shared sequence.
- Plus (+): the line appears only in the changed text and was added.
- Minus (−): the line appears only in the original text and was removed.
Rows are not numbered, and the view does not interleave renumbered copies of each side. You see one continuous stream that walks through the matched segments and the gaps in between, so the narrative of the file is preserved even when lines disappear or appear in clusters.
Run the Comparison in Three Steps
The following steps walk through the exact operating procedure for the Text Diff Checker. No installation, command-line arguments, or uploads are involved.
- Paste the original text on the left and the changed text on the right. Both fields accept plain text. Pasting replaces any content already in a field, and editing either side clears the previous comparison so the visible result always reflects the current state of both inputs.
- Select Compare lines. The tool validates both sides against the 500-line and 200,000-code-unit limits, then computes a longest-common-subsequence alignment between the two line arrays.
- Review plus additions, minus deletions, unchanged rows, and the summary counts. Scroll the unified result list and read the totals reported above or below the rows to confirm the magnitude of the change.
If either side exceeds the limits, the comparison is rejected before any computation runs and nothing is silently truncated. Re-paste a shorter excerpt or split the file first.
Why Line Matching Is Exact, Not Fuzzy
Two lines match only when their strings are exactly equal. This includes capitalization, every punctuation character, leading spaces, trailing spaces, tab characters, and every Unicode code point. If you change a single letter, swap a comma for a semicolon, add a trailing space, or replace an em dash with a hyphen, the affected line is reported as one deletion and one addition rather than as a subtle inline highlight.
This coarse behavior is deliberate. It keeps the comparison understandable for lists, configuration blocks, log entries, prose paragraphs, and small code excerpts, where a single changed line should be visible as a discrete event rather than blended into a character-by-character view.
The same rule means you should be careful with hidden whitespace. A pasted block from a word processor often carries non-breaking spaces or smart quotes that look identical to ordinary spaces and straight quotes but are different code points. Those invisible differences will show up as changed lines even when the visible text looks the same, so the diff is also a useful tool for spotting stray formatting carried over from a richer editor.
The comparison also recognizes different line-ending conventions. CRLF, standalone CR, and LF are all treated as line boundaries, and a CRLF pair counts as one boundary rather than two. The boundary syntax itself is normalized for analysis, while the content inside each line is preserved exactly as pasted.
Input Limits and Why They Exist
Each side is limited to 500 lines and 200,000 UTF-16 code units. A side that exceeds either limit is rejected before the dynamic-programming table is built, so a pasted huge document cannot freeze the tab and no partial comparison is produced.
| Constraint | Value | Reason |
|---|---|---|
| Maximum lines per side | 500 | Bounded quadratic work for longest-common-subsequence comparison. |
| Maximum characters per side | 200,000 UTF-16 code units | Bounds input storage and rendering memory. |
| Empty input | Treated as zero lines | Two empty inputs produce an empty result. |
| Empty line inside nonempty input | A valid line value | Blank lines participate in matching like any other line. |
| Line-ending normalization | CRLF, CR, LF recognized; CRLF = one boundary | Allows Windows, classic Mac, and Unix pastes to compare cleanly. |
The line cap exists because the underlying algorithm compares every line on the left with every line on the right as part of building the longest-common-subsequence table. Doubling the number of lines roughly quadruples the work, so an explicit cap keeps the browser responsive even on modest hardware. The character cap exists because each stored line and each rendered row consumes memory, and unbounded pastes would degrade the experience quickly.
Reading the Summary Counts
Above or below the row list, the tool reports three totals that match the visible prefixes.
| Prefix | Meaning | Counted as |
|---|---|---|
| Neutral | Line identical on both sides and included in the shared sequence | Unchanged |
| Plus (+) | Line present only on the right | Added |
| Minus (−) | Line present only on the left | Deleted |
The counts are derived from the same row types you see in the body, so the summary cannot disagree with the rendered view. If the totals look surprising, scroll the rows and confirm that whitespace or line-ending differences are not generating phantom changes.
When to Reach for a Different Tool
A browser-based line diff is the right fit when you have a short bounded text, want a fast local comparison, and care about seeing every line that changed. It is the wrong fit when the task outgrows those bounds or when you need capabilities the tool deliberately does not provide.
For a software project with many files, renames, history, authorship, and merge conflict resolution, use a source-control system such as Git rather than pasting individual files into a browser. For very large files, use a native streaming diff utility on your operating system so the comparison does not need to fit in a single tab. The tool also does not generate patch files suitable for automated application, does not detect moved blocks, does not ignore whitespace, does not fold letter case, does not parse programming languages, does not highlight character-level edits, and does not merge conflicts. If any of those capabilities are central to your task, choose a tool that was designed for them.
For a related list-style comparison, the Compare Two Lists tool produces union, common, A-only, B-only, and symmetric-difference outputs at once. For repeated cleanup that goes beyond comparison, Remove Duplicate Lines and Remove Empty Lines work well on a single source.
Privacy and Determinism
All splitting, comparison, row generation, and rendering happen in the current browser tab. Neither text is uploaded, and no third-party library or service is called as part of the comparison. After you close or refresh the page, the comparison and both inputs are gone.
The tool produces deterministic output: the same two inputs always yield the same ordered rows. The algorithm uses a fixed tie-breaking rule that favors an addition when the remaining subsequence lengths are equal, which matters when the two sides contain duplicate lines that could be aligned in more than one valid way. This property is useful when you want to confirm that a reported change is reproducible rather than a side effect of a non-deterministic alignment.
Equality reported by the tool is exact string equality under the documented rules, not semantic equivalence. Different Unicode normalization forms, visually similar characters, hidden whitespace, and line-ending conventions inside escaped strings can all register as differences even when the visible meaning appears unchanged. For sensitive changes, inspect them in the destination format and keep the original versions until review is complete.