Free Text Diff Checker

Compare two versions and see every change — private, in-browser, and free

Original text

Updated text

Comparison options

Ready to compare

Added lines 0
Removed lines 0
Unchanged 0
Similarity —
Compare texts to see changes

Your comparison will appear here

Added lines are green; removed lines are red

Example: compare a policy change

If a return period changes from 14 to 30 days, the diff marks the old line as removed and the new one as added. The unchanged line remains as context.

Original text

Returns are accepted within 14 days.
Items must be unused.

Updated text

Returns are accepted within 30 days.
Items must be unused.

What the diff shows

Returns are accepted within 14 days.
Returns are accepted within 30 days.
Items must be unused.

Compare two texts and find every change

A text diff checker compares two text versions line by line and identifies added, removed, and unchanged lines. Use this free online tool to review edits in drafts, contracts, notes, code snippets, or other plain text without scanning both versions manually.

Private by design: your text is compared in your browser and is not uploaded to a server. Use the case and whitespace options to focus on meaningful edits.

Text Diff Checker: key facts

  • Input: two text versions, pasted as an earlier and an updated version.
  • Method: line-by-line sequence comparison that preserves the order of the lines.
  • Results: added, removed, and unchanged lines, plus a line-based similarity percentage.
  • Options: ignore letter case or whitespace when matching lines; the displayed text remains unchanged.
  • Privacy: comparison runs locally in the browser; the text is not uploaded by this tool.
  • Size limit: comparison stops if its dynamic-programming table would exceed 2,000,000 cells. The limit depends on the line counts in both versions.

How to compare text online

  • Paste the earlier version into the Original text field.
  • Paste the newer version into the Updated text field.
  • Choose whether to ignore letter case or whitespace, then select Compare texts.
  • Review the added and removed lines, copy the result, or download a TXT report.

What the comparison shows

Green lines with a plus sign were added; red lines with a minus sign were removed; unchanged lines remain neutral. Similarity is based on the number of unchanged lines relative to both versions. If you ignore whitespace or case, those differences will not be treated as edits.

Frequently asked questions

What is a text diff checker?

A text diff checker compares two versions of text line by line and identifies added, removed, and unchanged lines. It shows textual differences; it does not judge whether an edit is correct or meaningful.

Is my text uploaded?

No. The comparison runs locally in your browser. The text is not sent to a server or saved by this tool.

Can I compare long documents?

Yes, for typical documents. To keep the page responsive, comparison stops if its dynamic-programming table would exceed 2,000,000 cells. This limit depends on the number of lines in both versions. Split very large texts into smaller sections and compare them separately.

What does Ignore whitespace do?

It removes whitespace characters within each line before matching. The original lines are still shown exactly as entered.

What a text comparison can—and cannot—tell you

A comparison is a map of visible textual changes, not a judgment about whether a revision is correct. It can tell you that a sentence disappeared, a number changed, or a paragraph was added. It cannot know whether the new wording is clearer, whether a figure is factually right, or whether a change was approved. That distinction matters when reviewing important material.

Treat the highlighted output as a checklist: inspect each change in its surrounding context, then make the decision yourself. A clean comparison can still contain a mistake if both versions share it, and a noisy comparison can still reveal a worthwhile edit. The tool is most useful when it helps a person read carefully rather than trying to replace that judgment.

Why the checker compares lines

Many documents are naturally organized into lines: source code, configuration files, notes, lists, plain-text drafts, and exported records. Comparing at this level makes the result easier to scan. A whole sentence that was inserted appears as one added line, while unchanged lines provide context around it.

Line-based comparison also keeps the original wording intact; the tool does not rewrite punctuation, normalize formatting for display, or silently merge paragraphs. There is a trade-off: if a long paragraph is edited in the middle, the entire line may appear as a removal and an addition.

Breaking a document into sensible paragraphs or using a character-level comparison tool may be better when the exact changed words inside a paragraph are the main concern.

A small example of reading a diff

Imagine the first version says “The report is due Friday” and the second says “The report is due Monday.” The comparison marks the original sentence with a minus sign and the new sentence with a plus sign. If the document also contains the unchanged line “Send the draft to the team,” that line remains neutral and helps you keep your place.

The red and green colors are aids, not the only signal: minus and plus markers are included so the meaning remains available to people who do not distinguish those colors. When the result has several consecutive changes, read the surrounding unchanged lines too. They often explain which section you are looking at and prevent an isolated phrase from being interpreted incorrectly.

How matching lines are selected

The checker finds an ordered set of lines that appears in both versions, then labels the remaining lines as additions or removals. In computer science, this is related to finding a longest common subsequence. “Ordered” is important: the same line can be present in both texts but still appear as a removal followed by an addition if it moved to a different position.

That behavior preserves the reading order and avoids pretending a moved paragraph is unchanged in place. Repeated lines can create more than one equally reasonable alignment. For example, a blank separator or a repeated heading may match the first occurrence in one comparison and the second occurrence in another. If an alignment seems surprising, check the repeated lines and nearby text before drawing a conclusion.

Understanding the similarity percentage

The percentage is calculated as twice the number of unchanged lines divided by the combined line count of both versions, then rounded to a whole number. When comparison options are enabled, matching uses the normalized lines; the original text is still displayed. This is not a semantic score, an edit distance, or a measure of writing quality.

A document can have a high percentage while its one changed line contains a critical date or price. Conversely, moving a large section can lower the percentage even if no words were rewritten. Use the number to answer a modest question—“How much of the line structure appears unchanged?”—and use the detailed output to answer “What exactly changed?”

When both texts are empty, there is nothing to compare; after a comparison, a 100% result means every line was matched under the selected options, not that the content has been independently verified.

When to ignore letter case

Turning on Ignore letter case treats uppercase and lowercase versions of a line as a match. This is handy for text where capitalization is inconsistent or not meaningful to the review, such as a list of labels, a set of keywords, or notes copied from different sources. It can also hide a meaningful edit.

In a product name, legal name, programming identifier, or acronym, capitalization may be part of the intended value. The original lines are still shown exactly as entered, but the comparison will not flag case-only differences while the option is active. If capitalization is part of what you are checking, leave this option off.

You can always run a second comparison with the option changed to see how the result differs.

When to ignore whitespace

Whitespace includes spaces, tabs, and line-internal spacing. Ignore whitespace removes those characters only for matching a line; the displayed line retains its original characters. This is useful when copied material has inconsistent indentation or spacing, or when you are checking wording rather than layout. It is not always appropriate. In source code, indentation can control program structure.

In a fixed-width data export, spaces may be meaningful. In a table copied from a document, spacing can communicate columns even when it is not part of the words. If a visual layout or formatting change matters, keep whitespace significant.

The safest habit is to compare once with the default settings, then use the option deliberately when you know which differences you want to set aside.

Blank lines, line endings, and paragraph boundaries

Text files can use different line-ending conventions, such as LF or CRLF. The checker recognizes common newline forms so that a file opened on one operating system can still be compared with a version from another. A blank line is still a line, however, and may be shown as added or removed when paragraph spacing changes.

A final newline can also create a trailing empty line in some editors. These details are often harmless, but they can matter in scripts, generated files, Markdown documents, and data files. If the output seems to report a change even though the words look identical, check the number of paragraphs, blank separators, and the final line break in each source.

The whitespace option does not erase entire line boundaries.

Reordering is different from rewriting

A moved paragraph is not necessarily a changed paragraph. Because the comparison preserves sequence, moving a block can appear as removed lines at the old position and added lines at the new one. This is useful when order is part of the document, but it can make a rearrangement look larger than it feels to a human reader.

For a short list, compare items one by one and confirm whether they were moved or rewritten. For a long document, use distinctive headings as landmarks and inspect each marked block in context. Do not infer that a sentence was deleted from the final document until you have searched the updated version; it may have been relocated.

Likewise, a newly marked paragraph may be an existing passage that was moved rather than new material.

Reviewing drafts, policies, and agreements

For a draft, comparison can quickly reveal edits made between review rounds: a new requirement, a removed caveat, or a changed date. For a policy or agreement, it can help direct attention, but it is not a substitute for a qualified legal review. Punctuation, numbering, cross-references, and a single negation can alter meaning.

A line-level tool may also mark a full paragraph when only one word changed. Keep the authoritative source files, verify that both versions are complete, and review every material change in context. When several people have edited a document, compare the version you approved with the exact version you received, not with a similarly named draft.

If a document carries legal or financial consequences, record who supplied each version and have the responsible reviewer confirm the final text.

Comparing code and configuration text

Developers can use a text diff for small code snippets, configuration files, error messages, or copied logs. It is especially useful when a full version-control diff is unavailable—for example, when checking a short change pasted into a support ticket. Leave Ignore whitespace off for languages where indentation or spacing affects behavior, including Python and many structured formats.

The checker does not parse a programming language, validate syntax, resolve imports, or execute code. It only compares the text supplied. Before applying a change, inspect surrounding lines, run the project’s formatter or tests, and use the source repository as the final record when one exists.

For large codebases, use version control: it can show file names, commits, renames, and context that a single-page text comparison does not know about.

Working with tables and exported data

Plain-text exports such as CSV, TSV, and log files can be compared line by line, which is helpful for spotting added records or changed rows. The result does not understand table columns. A comma inside quoted CSV data, a tab used as a field separator, or a wrapped line in a copied spreadsheet may therefore be difficult to interpret visually.

Keep both exports in the same format and encoding, and avoid opening and saving one version through an editor that silently changes quoting or line endings. If the question is whether two datasets contain the same records regardless of order, a line diff may be the wrong tool; sorting normalized copies or comparing structured data by key is more reliable.

Never assume that a matching row means every field is valid—inspect important identifiers and values separately.

Punctuation, numbers, and small but important changes

Short edits can carry more meaning than their visual size suggests. “Can” and “cannot,” a decimal point, a minus sign, a changed currency symbol, or one digit in an account reference may be critical. A line-level comparison flags the entire line, so read the exact characters rather than relying on color or similarity statistics.

Pay attention to hyphens and dashes, straight and curly quotation marks, nonbreaking spaces, and copied characters that look alike. This is particularly important in dates, measurements, version numbers, URLs, and identifiers. The tool is not a spell checker and does not decide whether “1,000” and “1.000” mean the same amount in different locales.

When precision matters, verify the value against the source record and the applicable format convention.

Languages, Unicode, and visually similar characters

The comparison keeps text as entered and handles ordinary Unicode characters in the browser. Two characters can look alike but have different code points—for example, a Latin letter and a Cyrillic letter, or a composed accented character and a base letter followed by a combining mark. Those characters may be treated as different even if they look the same on screen.

This is expected for a literal text comparison. The page does not normalize Unicode or translate content. If a match is important across copied text from different systems, check the original character source and encoding. For multilingual documents, also be aware that letter-case behavior varies by writing system; the Ignore letter case option is a convenience, not a language-aware linguistic analysis.

A reliable workflow for a quick comparison

Start with clear labels: identify which version is older and which is newer before pasting. Copy each source from the original file rather than retyping it, because manual entry can introduce changes before the comparison begins. Run the comparison with both options unchecked first; this preserves the fullest record of differences. Read every red and green line, including nearby neutral lines.

If formatting noise makes the result difficult to review, enable one option at a time and compare again. Once the changes are understood, use Copy diff for a message or Download TXT for a local note. Finally, open the updated source itself and verify that the change is present there. This workflow separates discovery from interpretation and reduces the chance of overlooking an important edit.

Reviewing changes with another person

When sharing a comparison, include the names or dates of the two source versions. The diff alone does not say where either source came from, who edited it, or whether it is the latest copy. If a reviewer flags a line, quote a short surrounding passage and point to the authoritative document instead of asking them to infer context from an isolated marker.

Do not send confidential text to someone who is not authorized to see it, even if the comparison was created locally. A downloaded report contains the changed content in readable form and should be handled with the same care as the source files.

For team review, agree on file naming and revision practices so that everyone compares the same pair of versions and knows which result is final.

What happens to your text

The comparison logic runs in the page using the text entered into the two fields. It does not need an account, does not request a document upload, and does not send the compared content to a text-diff service. The text is held in the current browser page while you work; clearing the fields or closing the page removes it from that page’s interface.

This is different from a promise that the entire device is private: browser extensions, shared-device history, clipboard managers, screenshots, or operating-system backups are outside the tool’s control. If you are working with sensitive material, use a trusted device, avoid copying the result to an unapproved destination, and close the tab when finished. Follow your organization’s rules for handling personal or regulated information.

Handling confidential material responsibly

Local processing can reduce the number of places a document travels, but it does not replace a security policy. Before comparing health, employment, customer, financial, or legal records, confirm that you are allowed to use the device and browser. Remove names or identifiers if they are not needed for the review, and do not store the downloaded diff in a public folder.

Be cautious on shared workstations: a later user may see a page left open, a copied value may remain in the clipboard, and browser extensions can have broad access depending on their permissions. If your employer requires an approved offline application, use that instead. The safest tool is the one that fits your organization’s process, not necessarily the one with the shortest workflow.

Why very large comparisons are limited

Finding an ordered set of matching lines requires work that grows with the sizes of the two inputs. An unrestricted comparison can make a browser tab unresponsive or allocate more memory than a phone can spare. This checker therefore stops a comparison when its line-pair table would exceed a practical limit and shows a message rather than silently returning an incomplete result.

If you reach that limit, split the document at a meaningful heading or section boundary, compare corresponding parts, and keep the original order. Avoid splitting in the middle of a table or paragraph if the relationship between lines matters. For repeated large comparisons, a desktop diff application or version-control tool is generally a better fit because it can handle files and show more context.

Choosing the right comparison tool

A browser text diff is a good fit for two short or moderate blocks that you can paste and review. A word processor’s Track Changes feature is better when authors need comments, acceptance or rejection of edits, formatting history, or attribution. A source-control diff is better for code projects because it preserves history and connects changes to commits.

A spreadsheet comparison is preferable when records need to be matched by an identifier rather than by row order. A binary or image comparison requires a tool designed for those formats; pasting their contents into a text field will not produce a meaningful review. Choosing the right tool prevents a neat-looking result from being mistaken for a complete audit.

Common reasons a result looks unexpected

If two passages that seem identical are marked differently, first check for a changed blank line, a trailing space, a different quote, or a line that was wrapped differently during copying. If a whole paragraph appears red and green, a single edit may have changed the paragraph’s line as a unit.

If many lines show as changed after a small reorder, the moved block may have shifted the best ordered alignment. If ignoring whitespace makes code look unchanged, remember that spacing can be meaningful in that language. If there are no changes, confirm that the right versions were pasted and that the comparison options reflect what you want to inspect.

These checks usually explain the result without requiring a different browser or an account.

Using Copy diff and Download TXT

Copy diff places a plain-text representation of the current comparison on the clipboard. Each line begins with a plus sign, minus sign, or neutral marker, which preserves the basic meaning in email, chat, or a text editor even when color is unavailable. Download TXT saves the same readable form as a local file. Neither action creates a formatted Word document or a signed audit record.

Before sharing the output, check that it contains no material you do not intend to disclose; deleted lines are still visible in a diff. If clipboard access is blocked by browser permissions, the page reports that the copy did not succeed rather than claiming success. You can still use the download action or select and copy the output manually.

Practical habits that improve reviews

  • Keep the original and updated versions intact; compare copies rather than overwriting a source.
  • Use descriptive file names or dates so you can identify which revision is on each side.
  • Start with strict comparison settings and relax them only to reduce irrelevant formatting noise.
  • Read removed content as carefully as added content; deletions are easy to miss in a long document.
  • Check numbers, names, dates, units, and negative wording separately.
  • For legal, financial, or safety-critical text, have the responsible person confirm the final version.
  • Keep the downloaded diff with the right project or record, not in an unlabeled temporary folder.

Related tools

Text comparison is often one step in a larger editing task. After reviewing a draft, use the Word Counter to check length, the Duplicate Remover to clean repeated lines, or the Case Converter to standardize capitalization. These tools do different jobs: run them only when you intend to transform the text, and keep the original version available for reference. If you are reviewing code, keep a repository diff as the authoritative record; this page is a convenient companion for pasted snippets, not a replacement for source control.