Toolivaro

Free Text Diff Checker

Compare two blocks of text line by line with added, removed, and unchanged highlighting plus change statistics — fully local.

The text diff checker compares two blocks of text line by line and shows exactly what changed: lines removed from the original, lines added in the new version, and the unchanged context between them, with a running summary of added, removed, and unchanged counts plus the proportion of changed lines. The comparison uses the classic longest-common-subsequence algorithm — the same approach GNU diff uses for its default output — so the result is deterministic and explainable: the tool shows the method, not a black box. An ignore-whitespace option treats lines that differ only in leading or trailing spaces as equal, which is useful when comparing code or config that was reformatted. Inputs are capped with an explicit truncation notice so the tab stays responsive even on huge pastes. Everything runs locally: the two texts — config files, CSS, generated output, drafts — never leave your device, are never logged, and are never stored. Use this tool to review a config change before deploying, to spot what a code formatter altered, or to diff generated output against a committed baseline.

Processed locally in your browser

How to use this calculator

When a text diff is the right tool

Some of the most expensive mistakes in software are the ones that look right: a config file that differs from the working version by a single character, a chunk of CSS that a formatter quietly rewrote, generated output that stopped matching its committed baseline. The diff checker is built for exactly these moments. Paste the original and the new version, and the tool highlights every line that was removed and every line that was added, with the unchanged lines between them for context — the same shape of output you get from diff-based review tools, minus the terminal. It is equally useful for documents that never touch a repository: comparing a contract draft to the version you signed, a copied email against the original, a report generated twice. Because everything runs locally, proprietary or personal text never leaves your device, which makes the tool the right choice when the content itself is sensitive.

Reach for this tool whenever “what changed?” is the question and you have both versions in front of you. Typical uses: reviewing a config change before you deploy it, checking what a code formatter did to a file you did not touch, diffing generated output against a baseline to confirm nothing regressed, or proving that two copies of a document are identical. It is also a fast sanity check for copy-paste work — paste the file you think you copied next to the source, and the diff tells you instantly whether you got it right. The tool is deliberately simple: two boxes, one button, one optional checkbox. If your question is about meaning rather than text — which version is correct, whether two JSON documents are semantically equal — this tool answers only the textual part, and judgment is yours for the rest.

One more scenario deserves its own mention: proving that two copies are identical. When a client sends back a “final” version of a contract or a teammate restores a config from a backup, a diff that comes back with every line unchanged is the cheapest proof there is — stronger than a glance, simpler than a checksum, and it leaves the evidence on screen. It also catches the silent regressions nobody files a ticket for: generated output that no longer matches its committed baseline, a minified bundle that changed after a dependency bump, a translated string that quietly reverted to the original language. Run the comparison once, watch the list come back green, and the “is anything different?” question is settled without reading either file end to end. The tool cannot tell you why a difference matters — that is judgment — but it can tell you, to the line, that a difference exists, and that certainty is most of what reviewing a change is about.

Comparing two texts, step by step

Paste the original version into the Original box and the new version into the Updated box — the only two required fields — then click Compare. The result panel opens with a stat grid: added lines, removed lines, and the percentage of lines that changed, plus the full line-by-line list underneath. The Ignore whitespace checkbox sits next to the Compare button; tick it when lines that differ only in leading or trailing spaces should count as equal. That option is the difference between a noisy diff and a useful one when a formatter reindented a file or a paste added stray spaces. Line endings are handled for you: Windows CRLF breaks are normalized to LF before comparison, so a file saved on Windows compares cleanly against one saved on macOS or Linux.

Three pitfalls cover most confusion. First, the comparison is line-based: a single word changed inside a long line shows up as that whole line removed plus a whole line added, never as a word-level edit — so a small change can look like two big ones. Second, reindentation counts as a change unless you tick Ignore whitespace, and even then only leading and trailing spaces are ignored, not spaces inside the line. Third, inputs are capped at 4,000 lines; beyond that the tool trims the input and shows an explicit truncation notice instead of freezing the tab, so watch for the notice when the numbers look small for a very large file. And remember the tool compares text, not meaning — identical text can still be wrong content, and different text can be right.

Reading the diff results

The results panel has two parts. The stat grid shows added and removed line counts plus the percentage of changed lines — that figure is added plus removed divided by the total number of lines shown in the diff, rounded to a whole percentage. Below it, the list renders every line of both versions in order: added lines in green with a plus marker, removed lines in red with a minus marker, and unchanged context lines with a blank marker. Reading the list top to bottom tells the story of the change the same way a code review does: this line left, that line arrived, everything else stayed. After each comparison a summary restates the counts in plain words — “1 added, 1 removed, 3 unchanged” — so you never have to do the arithmetic yourself.

There is little that can go wrong, and the tool surfaces what there is. Comparing two empty boxes yields no added or removed lines and a 0% change figure, and the same is true of two identical files — every line comes back as unchanged context, which is the tool’s most useful answer when you feared a silent difference. Over the 4,000-line cap, a truncation notice appears above the list so you know the numbers cover only the first part of the document — treat those results as partial. The one thing the output never tells you is which version is correct: the diff marks a deleted line and its replacement with equal confidence, so verify intent against the data before you act on the result. That judgment is the part no diff tool can do for you.

How is the result calculated?

A one-line config change

Comparing a config file before and after a retry-timeout change: the diff shows one removed line (timeout = 30), one added line (timeout = 60), and the two surrounding lines — the host and the retries setting — unchanged. Of the four lines the diff displays, two changed, a 50% change ratio.

Input Value
original host = api.example.com timeout = 30 retries = 3
updated host = api.example.com timeout = 60 retries = 3
Result 1 added · 1 removed · 2 unchanged · 50% changed

Finding the real change after a formatter reindented your CSS

Your CSS linter was configured to switch indentation from two spaces to four, and it reformatted a whole stylesheet. The file differs everywhere, but what you need to know is whether anything actually changed. Paste the pre-format and post-format versions, tick Ignore whitespace, click Compare, and the noise disappears: lines that differ only in indentation are treated as equal, so the diff shows the stylesheet’s structure as unchanged context and highlights just the genuine edit — font-size moving from 14px to 15px. The stats confirm the story: 1 added, 1 removed, 3 unchanged, 40% changed. Reading this diff is like scanning a photograph for one changed pixel: the eye needs the surrounding image to know where to look, and the unchanged context lines are that frame. Without the option, the same inputs produce 2 added and 2 removed lines — the two indented lines count as fully rewritten — which is accurate but unhelpful when all you want to know is whether the formatter altered anything besides indentation. The checkbox compares each pair of lines after trimming leading and trailing spaces, so “ color: red;” and “ color: red;” count as the same line. It is the whole point of the option: separate whitespace churn from the real delta, and the result reads like a one-line changelog instead of a rewrite. Keep it in mind any time a formatting tool touched a file you did not intend to change — it turns a diff that looks like a rewrite into one you can read in ten seconds.

Input Value
original body { color: red; font-size: 14px; }
updated body { color: red; font-size: 15px; }
Result 1 added · 1 removed · 3 unchanged · 40% changed

Reviewing a server config edit before deploy

An nginx-style server block changes before a deploy: the listen port moves from 80 to 443, and the root directive disappears because the site is now served from static files. Diffing the old and new blocks shows the exact shape of the edit — listen 80 removed, listen 443 added, server_name, index, and both brace lines unchanged, and the root line removed — for a result of 2 removed, 1 added, 4 unchanged, 43% changed. Reading the result is like checking a passenger manifest against yesterday’s list: each line either stayed, was replaced, or left the flight, and the unchanged names give you the context to spot the two that matter. The order in the list matters too: the removed listen 80 line sits directly above the added listen 443 line, so the eye sees a swap rather than an unrelated pair of events, while the deleted root line stands alone further down — a removal with no replacement, exactly the kind of change that deserves a second look before it ships. The brace lines and the server_name line anchor the block; without that context the removed and added lines would float in a list and the story of the change would be much harder to read. A diff this small is the easy case; the same habit pays off on hundred-line files where the one real change hides among reformatting. Run the comparison, read the removed lines first, and confirm each one was intentional before you deploy — a minute of checking beats discovering the edit after the deploy.

Input Value
original server { listen 80; server_name example.com; root /var/www/html; index index.html; }
updated server { listen 443; server_name example.com; index index.html; }
Result 1 added · 2 removed · 4 unchanged · 43% changed

What is the formula and its assumptions?

Diff method

diff = longest-common-subsequence(left, right) over lines

Symbol Meaning
left original text, split into lines
right new text, split into lines
LCS the longest sequence of lines present in both inputs in order

Lines outside the LCS are reported as removed (from the left) or added (from the right); the LCS itself is unchanged context.

What are the most common mistakes?

  • Expecting word-level granularity from a line-based diff — lines are atomic here.
  • Comparing texts with different line endings (CRLF vs LF) — they are normalized first, which can mask or reveal changes depending on the source.
  • Forgetting the ignore-whitespace option when reformatting changed indentation everywhere.
  • Uploading proprietary or personal text to an online diff service — this tool is fully local.

What are the assumptions and limitations?

  • The comparison is line-based, not word-based or semantic.
  • Inputs are capped (with an explicit notice) to keep the page responsive.
  • The tool reports textual differences — it cannot judge which version is correct.

Where do the numbers come from?

Last reviewed August 12, 2026 · Version 1.1.0 · Toolivaro does not guarantee external content.

Frequently asked questions

Is this the same algorithm as git diff?

Conceptually yes — git’s default diff also aligns files around a longest common subsequence, with refinements (like Myers’ algorithm) for speed. The result for typical text is the same shape of added, removed, and unchanged lines; this tool documents its method openly and caps inputs for responsiveness.

Why does the diff sometimes show more changes than I expected?

Line-based comparison treats whole lines as atomic. If one line changed in the middle, that line is one removal plus one addition — not a word-level edit. Reformatted code (new wrapping, reindentation) can therefore produce large diffs even though the meaning is unchanged.

Does the tool handle very large files?

Yes, with a documented cap: inputs beyond the line limit are truncated with an explicit notice rather than freezing the tab. For files in the tens of thousands of lines, a purpose-built diff tool is the better choice.

What happens if my texts have Windows line endings?

Line endings are normalized before comparison: CRLF (\r\n) is converted to LF (\n) on both sides. A file saved on Windows compares cleanly against one saved on macOS or Linux, and a change in line-ending style alone produces no added or removed lines. If you have ever seen a whole-file diff in git for a one-line edit, that is usually the same problem — this tool handles it for you.

How is the changed percentage calculated?

The change ratio is added plus removed lines divided by the total number of lines shown in the diff, rounded to a whole percentage. The total includes unchanged context lines, so the figure depends on how much context surrounds the changes. Treat it as a rough measure of how much text moved — not as a measure of how significant the change is.

Can I drag and drop files to compare?

No — this tool accepts pasted text only. Open each file in your editor, select all, copy, and paste into the Original and Updated boxes, then click Compare. That keeps the tool dependency-free and everything local, and for typical files the whole flow takes a few seconds. For very large files, remember the 4,000-line cap applies to whatever you paste.

Part of Developer text and JSON toolkit

Found a mistake or have a correction? Report it — we review every correction.

Was this helpful?

Reviewed by the Toolivaro editorial team per our methodology Methodology · Editorial policy