Line-by-Line Text Diff: Why One Inserted Line Changes Everything After It
Paste the original and the revised version, and the output marks lines only in the original with a minus and lines only in the revision with a plus. Matching is by line number, not by longest common subsequence, so inserting one line flags every line below it.
Open the tool：Line-by-Line Text Diff
When a line diff is the right tool
You edited a paragraph and want to know which sentences moved, you are checking whether two config files have drifted apart, a subtitle file may have lost its timing, a colleague sent back a contract with one number changed. Each of these needs which line changed, not a reread of both documents.
A line diff also leaves a record: pasting the result into a ticket or an email shows exactly which lines were added or removed, without asking anyone to open two files side by side. For people who cannot install Git or a diff tool, a browser page is the shortest path.
- Checking a copy edit before and after
- Comparing config files and environment variables
- Line-level checks on subtitles and scripts
How to compare without fooling yourself
The single most important thing is that the two texts line up. Line 1 is compared with line 1 and line 2 with line 2, so after you insert one line in the middle, every following line shifts by one position and is reported as changed. That is not a bug; it is how a positional diff behaves.
Normalise line endings before pasting. If one side uses Windows CRLF and the other uses LF, editors may look identical while a character-by-character comparison marks whole blocks as different. Trailing spaces count too, so trim line ends on both sides first and the output becomes much easier to read.
- Re-align the two texts after inserting or deleting a line
- Use the same line endings, CRLF or LF, on both sides
- Trim trailing spaces to avoid whole-block false positives
Where it stops, and what to use instead
It compares whole lines and never shows which word inside a line changed; that needs a character-level diff. To find the smallest set of edits across many lines — one inserted line rather than ten replaced ones — you need a longest-common-subsequence diff, which is what Git, the diff command, and side-by-side editor views provide.
It also has no ignore-case, ignore-whitespace, or ignore-blank-line option. For code review or large files a local diff tool is better: it collapses unchanged regions, highlights by word, and does not require pasting an entire codebase into a browser tab.
- Word-level highlighting needs a character diff
- Large files and repositories belong in Git or your editor
- Ignoring case or whitespace needs a dedicated diff tool
FAQ
Why did adding one line in the middle mark everything after it as changed?
Because lines are matched by position, not by content. Once you insert a line, the old line 5 becomes line 6 and no longer pairs with line 5 on the other side, so every line below reads as different. Re-align the two texts and run it again to see the real change.
Can it ignore differences in case or spacing?
No. Only an exact match counts as unchanged, so a trailing space or a capital letter marks the line as different. Trim line ends on both sides before pasting, and normalise case yourself if that difference does not matter to you.
What happens if the two texts have different line counts?
Nothing breaks. Extra lines are marked wholly as deleted or added, which shows up as a run of minus or plus lines. It is easier to judge if you first check whether those lines are real content or just a trailing blank line at the end of one file.
Related tool：Line-by-Line Text Diff