Text Diff Tool compares two blocks of text and highlights the differences between them. Paste any two versions of code, documents, or configuration files to see insertions (green), deletions (red), and unchanged lines side by side or in unified diff format. The diff output follows the standard diff algorithm used in version control systems like Git.
The diff algorithm used in most tools is the Myers diff algorithm (1986), which finds the shortest edit script — the minimum number of insertions and deletions needed to transform text A into text B. Git uses a refined version with heuristics for large files. The Patience diff algorithm (used by Bazaar and optionally Git: git diff --patience) produces diffs that are more readable for human review by finding unique lines as anchors.
Common use cases: comparing two versions of a configuration file before deploying, reviewing API response changes, checking before/after refactoring, spotting differences in log files, or validating that a document edit only changed what was intended.
Compare config files
Result: - timeout: 30\n+ timeout: 60\n retries: 3 → timeout changed from 30 to 60
Find API response changes
Result: Old: {"status":"ok","count":5} / New: {"status":"ok","count":7,"page":1} → count and page fields differ
Unified diff format
Result: @@ -1,3 +1,4 @@ / -timeout: 30 / +timeout: 60 / retries: 3 / +max_retry_wait: 5
What is the difference between unified diff and side-by-side diff?
Unified diff shows both versions in a single pane with + and - prefix markers on changed lines (deletions are -, insertions are +, unchanged are space). One line with context is shown around each change. Patch files use unified diff format. Side-by-side diff shows the two versions in parallel columns with changed lines highlighted in each column — easier to read for humans but takes more screen space. git diff generates unified diff by default.
How does Git's three-way merge work?
Three-way merge compares: the common ancestor (merge base), version A (your branch), and version B (the other branch). If only A changed a line → use A. If only B changed → use B. If both changed the same line differently → conflict. The merge base is found with git merge-base branchA branchB. This is more accurate than a two-way diff (just A vs B) because it can distinguish 'A deleted a line' from 'A never had the line.'
What is a patch file?
A patch file is a text file in unified diff format that describes changes to apply to a source. You create one with: git diff > changes.patch. Apply it with: git apply changes.patch (or patch -p1 < changes.patch). Patch files are used to share code changes without a shared git repository, submit bug fixes to open source projects via mailing lists (Linux kernel uses this workflow), and apply vendor patches to open source code without forking.
What is the difference between character-level and line-level diff?
Line-level diff (standard) treats each line as a unit — a change to one character marks the whole line as changed. Character-level (or word-level) diff shows exactly which characters changed within a line. Git supports word diff: git diff --word-diff. This is more readable for prose text where one word changes in a long line. For code, line-level diff is usually preferred because line context is meaningful.
How do I generate a diff in the terminal?
diff -u file1.txt file2.txt produces unified diff output. git diff shows working directory changes. git diff HEAD~1 HEAD shows changes in the last commit. git diff branch1..branch2 compares branches. diff -r dir1 dir2 recursively compares directories. To create a patch: git diff > my.patch. To apply: git apply my.patch or patch -p1 < my.patch.