Verificador de diferencias de texto

What a diff really tells you

A diff answers one precise question: what changed between two versions of a text? Rather than forcing you to read both versions side by side and spot the differences by eye, a diff tool computes the smallest set of edits — lines added, lines removed — that turns the original into the modified version. This checker compares your two texts line by line: it splits each block on newlines and then aligns the two lists of lines, marking removed lines in red on the left and added lines in green on the right, with unchanged lines shown in neutral colour on both sides. Everything runs in your browser, so neither version is ever uploaded — you can compare confidential code or contracts with nothing leaving your device.

The algorithm: longest common subsequence

Under the hood this tool uses the classic longest common subsequence (LCS) method, the same idea behind the Unix diff command and the line view in version-control systems. The "subsequence" is the longest sequence of lines that appears, in order, in both texts — they need not be adjacent. Once the tool finds that common backbone, everything on the original side that is not part of it must have been deleted, and everything on the modified side that is not part of it must have been added. The matcher fills a grid comparing every line of the original against every line of the modified version, scoring how many lines they share, then walks back through that grid to reconstruct the exact edit sequence. The result is a minimal, stable diff that doesn't flag a line as changed just because lines around it moved.

A worked example

Put this in the Original panel:

• function total(items) {
• return items.length;
• }

And this in the Modified panel:

• function total(items) {
• const n = items.length;
• return n;
• }

The first line and the closing brace are identical, so they form the common backbone and stay neutral on both sides. The line return items.length; exists only in the original, so it is marked red as a deletion on the left. The two new lines const n = items.length; and return n; exist only in the modified version, so they are marked green as additions on the right. The stats bar reports +2 lines added, −1 lines removed. Note that because the comparison is line-based, a line where you changed even a single character counts as one deletion and one addition — the old line is removed and the new line is added, rather than the change being shown within the line.

How the panels line up

The output is a true side-by-side view. Whenever a line is deleted, a blank placeholder appears in the matching slot on the right so the two columns stay vertically aligned; the same happens on the left for an added line. That alignment is what lets your eye track a single logical change straight across both panels instead of guessing which red line corresponds to which green one. The comparison also runs automatically a fraction of a second after you stop typing, so you can edit either side and watch the diff update without pressing the button.

Use cases

• Code review. Paste the old and new version of a function or config file to see exactly which lines a change touched before you commit it.
• Proofreading edits. Compare a draft against a revised document to confirm an editor changed only what you expected.
• Tracking config drift. Diff a known-good settings file against the one running in production to spot an accidental edit.
• Reconciling pasted data. Check whether two lists — emails, IDs, dependency versions — actually differ, and where.

Tips and common pitfalls

• Watch invisible whitespace. Because matching is exact, a trailing space or a tab-versus-spaces difference makes two lines that look identical register as a deletion and an addition. Normalise whitespace first if you only care about meaningful changes.
• Line endings matter conceptually but not here. The tool splits on the newline character, so the count of lines is what drives the comparison — keep both sides in the same overall structure for the cleanest result.
• Reordered lines look like delete-plus-add. Moving a block down counts as removing it from its old position and adding it lower; a line-diff has no concept of "moved", so don't read a move as unrelated edits.
• Big inputs cost more. LCS compares every original line against every modified line, so very large texts take noticeably longer. For huge files, diff the relevant section rather than the whole thing.
• This is a line diff, not a word diff. If you need to see which words changed inside a sentence, split the sentence across lines first, or treat each changed line as a fresh comparison.