⇄ Text Compare — Side-by-Side Text Diff Tool
Compare two texts side by side with word-level diff highlighting. Supports file upload. Line-by-line and inline view. Free online text comparison tool.
Paste your original and modified texts into the two panels and click Compare. Changed lines are highlighted by color — green for additions, red for deletions. Word-level highlighting shows exactly which words changed within a line. Supports plain text, code, JSON, and any other format.
How to Use
Paste or upload texts
Enter your two texts in the left and right panels. Use the upload button to load files directly.
Choose view mode
Switch between Split view (side by side) and Inline view (unified diff) using the toggle.
Review the changes
Green lines were added, red lines were removed. Changed lines show word-level highlights inside.
Frequently Asked Questions
Complete Guide: Diff Checker
A diff checker compares two blocks of text and highlights what changed between them. Whether you're reviewing code, comparing configuration files, or auditing API responses, understanding how diffing works under the hood helps you get the most out of every comparison tool.
The Myers Diff Algorithm
Most diff tools — including Git — use the Myers diff algorithm, published by Eugene Myers in 1986. Conceptually, it models diffing as a shortest-path problem on a graph where each node represents a position in both texts. Moving right means "take a character from text A," moving down means "take from text B," and moving diagonally means "the characters match — keep them." The algorithm finds the path with the fewest edits (insertions + deletions), producing the shortest edit script.
This explains why a diff output is not always what a human would consider the most "readable" change — the algorithm optimizes for minimum operations, not narrative clarity.
Unified vs Side-by-Side View
Diff tools typically offer two presentation modes:
- Unified view — changes are shown in a single stream. Lines prefixed with - were removed; lines with + were added. This is the default format for
git diffand patch files. - Side-by-side view — the original and modified text appear in two columns. Deletions appear on the left, additions on the right. This mode is easier for humans to read when changes are spread across many lines.
Line-Level vs Character-Level Diff
A line-level diff treats each line as an atomic unit. It tells you which lines were added or removed but doesn't highlight what changed within a line. A character-level diff (also called word-level or inline diff) goes deeper: after identifying a changed line, it runs a second diff pass on the characters within that line and highlights the exact span that changed.
// Line-level (only knows the whole line changed):
- const timeout = 3000;
+ const timeout = 5000;
// Character-level (highlights just "3" → "5"):
const timeout = <del>3</del><ins>5</ins>000;
Context Lines
By default, unified diffs show 3 context lines above and below each changed block. These unchanged lines give you enough surrounding code to understand what was modified without reading the entire file. You can adjust this — git diff -U10 shows 10 context lines, while -U0 shows only changed lines with no context.
Ignoring Whitespace
Whitespace-only changes (indentation, trailing spaces, blank lines) are frequent noise in diffs, especially after auto-formatting. Most diff tools offer an option to ignore whitespace. In Git:
- git diff -w — ignore all whitespace changes
- git diff --ignore-space-change — ignore changes in the amount of whitespace
- git diff --ignore-blank-lines — ignore changes that only add or remove blank lines
Common Use Cases
- Code reviews — comparing a feature branch to main before merging
- Config file auditing — spotting the difference between a staging and production
nginx.conf - API response comparison — checking what changed between two versions of an endpoint's JSON output (see also JSON Diff)
- Database migrations — verifying schema changes before applying to production
- Documentation tracking — confirming what actually changed between two releases of specs or changelogs
Semantic Diff Limitations
Standard diff tools are syntactically aware but semantically blind. They cannot tell that renaming a variable throughout a file is one logical change — they see dozens of individual line edits. Similarly, moving a function from one location to another appears as a full deletion and a full addition, even though no logic changed. Semantic diff tools exist for some languages (like difftastic, which parses source code into ASTs) but are not yet universally supported.
Git Diff Internals
When you run git diff, Git compares blob objects stored in its object database. Git first computes the SHA-1 hash of each file version; if the hashes match, no diff is run. Otherwise, it applies the Myers algorithm on the file contents, outputting a patch in unified diff format. The .git/objects directory stores every version of every tracked file, which is why Git can diff any two commits instantly without needing the original files on disk.
For comparing structured data rather than plain text, try our JSON Diff tool, which understands key ordering and nested structures. For plain text comparisons, see Text Diff.