Does the Diff Checker send my text to a server?

No. All comparison logic runs entirely in your browser using JavaScript. Your text is never transmitted to any server and is not stored anywhere remotely.

What algorithm does the diff use?

The tool uses the Longest Common Subsequence (LCS) algorithm to produce a minimal line-level diff. For lines that were partially changed, it runs a second character-level LCS pass so you can see exactly which characters were added or removed within a line.

What is the difference between Unified and Side-by-Side views?

Unified view shows all changes in a single list: deleted lines in red above added lines in green, prefixed with − and + sigils. Side-by-side view places the original on the left and the modified on the right, aligning paired changed lines on the same row for easier visual comparison.

Is there a text size limit?

There is no hard limit. The LCS algorithm is O(m × n) in time and memory, so very large files (thousands of lines) may take a moment to process. Character-level diff on individual lines longer than ~450 characters falls back to whole-line highlighting to keep the UI responsive.

Can I compare code files?

Yes. The diff checker works on any plain text — source code, configuration files, markdown, JSON, CSV, prose, or anything you can paste into a text field. It does not apply language-specific formatting, so the comparison is purely text-based.

Diff Checker

Paste two texts to compare them line by line. Highlights every addition, deletion, and character-level change — unified or side-by-side view.

Original

Modified

Unified Diff

difference

Paste text in both panels above to compare.

Why use our online Diff Checker?

Find line-by-line differences between two blocks of text directly in your browser. Ideal for comparing code versions, document revisions, or config files — your content never leaves your device.

How to use Diff Checker

1
Paste your original text
Click the Original panel on the left and paste the baseline version of your text — a file, a config snippet, a draft, or any content you want to compare.
2
Paste the modified text
Click the Modified panel on the right and paste the updated version. The diff updates instantly as you type.
3
Choose a view mode
Select Unified to see additions and deletions in a single scrollable column, or Side by Side to view the two versions next to each other with matching lines aligned.
4
Read the highlighted differences
Green lines are additions, red lines are deletions. For lines that changed partially, individual characters are highlighted within the line so you can spot small edits at a glance.
5
Copy or swap the result
Click Copy diff to copy the full unified diff to your clipboard. Use the Swap button to reverse original and modified, or Clear to start a new comparison.

How the LCS diff algorithm works

The diff algorithm used by this tool — Longest Common Subsequence (LCS) — is the same algorithm used by the Unix diff command, git diff, and most code review tools. Given two sequences (the original and modified text), LCS finds the longest subsequence of lines that appears in both — these are the "unchanged" lines. Everything in the original that is not in the LCS is a deletion; everything in the modified version that is not in the LCS is an addition.

The algorithm builds a matrix of size (m+1) × (n+1), where m and n are the lengths of the two sequences, and fills it using dynamic programming. The time and space complexity is O(m × n), which means it scales quadratically with document size. For very large files (thousands of lines), this can be slow. Git uses an optimized "patience diff" algorithm that produces more readable diffs for code by preferring to align unique lines — useful for refactored code where many lines moved rather than changed.

Once the line-level LCS is computed, this tool runs a second character-level LCS pass on pairs of lines that were changed, highlighting exactly which characters were added or removed within each changed line. This inline character diff is what makes it easy to spot small edits like a changed variable name or a corrected typo.

Unified vs side-by-side view — which to use

Unified diff view places all changes in a single scrollable column. Deleted lines are shown in red with a minus prefix; added lines are shown in green with a plus prefix. Unchanged context lines appear in grey. This is the format used by git diff in the terminal and in most patch files. It is compact and works well when changes are sparse — a few lines scattered through a long document.

Side-by-side view shows the original on the left and the modified version on the right, with corresponding lines aligned horizontally. Changed lines in the original highlight red on the left; their replacements highlight green on the right. This view is much easier to read when changes are dense — many lines modified in sequence — because your eye can immediately compare the before and after on the same screen row.

The practical guide: use unified view for quick scans and for generating patch content to copy. Use side-by-side view for careful review of complex changes where you need to compare each modified section in detail. Most code review platforms (GitHub, GitLab, Bitbucket) offer both views for exactly this reason.

Practical uses for a text diff tool

Text diffing is most commonly associated with code, but it is useful in many non-programming contexts.

Document revision tracking: when collaborating on contracts, proposals, or policy documents without tracked changes enabled, paste the old and new versions to identify every change made. Particularly useful when someone sends a "revised" document without indicating what changed.

Copy editing: paste the original draft and the edited version to verify that only the intended changes were made and nothing was accidentally deleted or altered.

API response debugging: paste two JSON responses from different environments (staging vs production, before and after a deployment) to find field changes, missing keys, or value differences. Format both through the JSON formatter first to normalize indentation before comparing.

Config file comparison: diffing nginx configurations, Kubernetes YAML files, or Dockerfile versions reveals exactly what changed between working and broken states — far faster than reading both files manually.

Data validation: compare expected vs actual CSV output, SQL query results, or log entries to find discrepancies in automated tests or data pipelines.

Frequently Asked Questions

Does the Diff Checker send my text to a server?: No. All comparison logic runs entirely in your browser using JavaScript. Your text is never transmitted to any server and is not stored anywhere remotely.
What algorithm does the diff use?: The tool uses the Longest Common Subsequence (LCS) algorithm to produce a minimal line-level diff. For lines that were partially changed, it runs a second character-level LCS pass so you can see exactly which characters were added or removed within a line.
What is the difference between Unified and Side-by-Side views?: Unified view shows all changes in a single list: deleted lines in red above added lines in green, prefixed with − and + sigils. Side-by-side view places the original on the left and the modified on the right, aligning paired changed lines on the same row for easier visual comparison.
Is there a text size limit?: There is no hard limit. The LCS algorithm is O(m × n) in time and memory, so very large files (thousands of lines) may take a moment to process. Character-level diff on individual lines longer than ~450 characters falls back to whole-line highlighting to keep the UI responsive.
Can I compare code files?: Yes. The diff checker works on any plain text — source code, configuration files, markdown, JSON, CSV, prose, or anything you can paste into a text field. It does not apply language-specific formatting, so the comparison is purely text-based.