Text Diff

What is Text Diff?

Text diff (difference) is a tool that compares two text documents and highlights what has changed between them. It shows additions (new lines), deletions (removed lines), and unchanged content. Diff tools are essential in software development for code reviews, version control (git diff), configuration management, and debugging. The concept originated with Unix's diff command in 1974, which introduced the line-by-line comparison algorithm still used today. Modern diff tools add visual enhancements like syntax highlighting, side-by-side views, and word-level granularity. Unlike simple text comparison that only says 'files differ', diff tools show exactly where and what changed, making it easy to spot typos, unintended modifications, or specific code changes. Diff output can be saved as patch files (.diff or .patch) which can be applied to other files, making it a cornerstone of collaborative development.

How to Use This Text Diff Tool

• 1. **Paste Original Text**: Copy your original text into the left textarea (labeled "Original Text")
• 2. **Paste Modified Text**: Copy the modified version into the right textarea (labeled "Modified Text")
• 3. **Select View Mode**: Choose between Side-by-Side, Unified, or Inline view
• 4. **Configure Options**: Enable "Ignore Whitespace" to skip spacing differences, toggle "Case Sensitive" for case-insensitive comparison
• 5. **Review Differences**: The diff view automatically updates showing additions (green), deletions (red), and unchanged lines
• 6. **Check Statistics**: View added, removed, and unchanged line counts at the top
• 7. **Copy Diff**: Use "Copy Diff" button to copy the unified diff format to clipboard
• 8. **Load Sample**: Click "Load Sample" to see an example comparison
• 9. **Swap Texts**: Use "Swap Texts" to reverse left and right panels
• 10. **Clear All**: Click "Clear" to reset both text areas and start fresh

Diff View Modes Explained

Our tool offers three complementary view modes. **Side-by-Side View** displays original and modified text in parallel columns with line numbers, making it easy to see both versions simultaneously. This is ideal for comparing large files or when you need to reference both versions. Lines are aligned vertically so you can quickly spot where changes occur. **Unified Diff View** shows all content in a single column with + prefix for additions, - prefix for deletions, and no prefix for unchanged lines. This is the standard format used by git diff, patch files, and GitHub/GitLab pull requests. It's more compact than side-by-side and better for copying or sharing diffs. **Inline View** blends changes into a single text flow with colored highlights - green background for additions, red background with strikethrough for deletions. This view is best for seeing the final result with changes integrated, useful for proofreading or understanding the net effect of changes. Choose the view that matches your workflow: side-by-side for detailed analysis, unified for standard diff format, inline for reading flow.

Common Use Cases

• **Code Reviews**: Compare code before and after changes during pull request reviews
• **Git Diffs**: Understand what changed in commits, branches, or between working directory and staging
• **Configuration Files**: Compare production vs development configs (nginx.conf, docker-compose.yml)
• **Documentation**: Track changes in README files, API docs, or technical specifications
• **Log Analysis**: Compare log files from different time periods to spot anomalies
• **Contract Review**: Compare document versions to track legal or business terms changes
• **Translation Files**: Compare i18n/localization files to see new or modified translations
• **Database Schemas**: Compare SQL schema dumps to track database migrations
• **API Responses**: Compare JSON/XML responses before and after API changes
• **Environment Variables**: Compare .env files across environments (dev, staging, prod)

Ignore Whitespace vs Case Sensitive

These two options control how the diff algorithm treats content. **Ignore Whitespace** (when enabled) compares text at the word level instead of line level, treating multiple spaces, tabs, and line breaks as equivalent to a single space. This is useful when formatting changes (indentation, line wraps) obscure the actual content changes. For example, reformatting code with Prettier will show 100% changed lines without this option, but with it enabled, you'll only see actual code changes. However, for languages where whitespace is significant (Python, YAML), keep this disabled. **Case Sensitive** (when enabled, default) treats 'Hello' and 'hello' as different. Disabling it makes comparisons case-insensitive, useful when comparing text where case doesn't matter (documentation, prose) or when you want to ignore capitalization changes. Note that disabling case sensitivity converts all text to lowercase internally, so the diff output will show lowercase. These options are independent: you can ignore whitespace while remaining case-sensitive, or vice versa.

Understanding Diff Algorithms

Diff tools use sophisticated algorithms to compute the shortest sequence of changes. The most common is the **Myers Diff Algorithm** (1986), which finds the longest common subsequence (LCS) between two texts and minimizes the edit distance. It's efficient (O(ND) time complexity where N is file size and D is edit distance) and produces intuitive diffs. Other algorithms include **Patience Diff** (used by git --patience), which handles moved blocks better by first matching unique lines, then recursively diffing the rest. **Histogram Diff** (git default since 2.30) is similar to patience but uses a different heuristic for finding anchors. For word-level diffs, **Wagner-Fischer Algorithm** (edit distance) is used. Our tool uses the standard Myers algorithm via the 'diff' library, balancing speed and accuracy. The algorithm works by building a grid where each cell represents matching or non-matching lines, then finding the shortest path through the grid. This is why diff results are optimal - they minimize the number of changes shown.

Diff in Version Control (Git)

Git diff is one of the most-used commands in software development. **git diff** shows unstaged changes (working directory vs staging area). **git diff --staged** shows staged changes (staging area vs last commit). **git diff commit1 commit2** compares two commits. **git diff branch1..branch2** compares branches. **git diff HEAD~1** shows changes in the last commit. Git diff output uses unified diff format: lines starting with - are removed, + are added, @@ markers show line numbers (e.g., @@ -10,5 +10,7 @@ means starting at line 10 of the old file, 5 lines shown, and line 10 of new file, 7 lines shown). Git also shows context lines (unchanged lines around changes) to help locate changes. You can customize git diff with options like --word-diff (word-level), --color-words (word-level with colors), --ignore-all-space, --ignore-blank-lines. For better diffs of moved code, use --color-moved. GitHub and GitLab's pull request UI builds on git diff, adding inline comments, suggestion features, and file tree navigation.

Creating and Applying Patches

Patches are diff output saved to files (.diff or .patch) that can be applied to other files. This is how open-source projects accept contributions before git became universal. To create a patch: run diff originalFile modifiedFile > changes.patch (Unix) or copy unified diff output from our tool. The patch file contains the diff in unified format with file headers. To apply a patch: use patch originalFile < changes.patch (Unix). In git, you can create patches with git format-patch commit-ref which creates patch files for each commit, or git diff > my-changes.patch for uncommitted changes. Apply with git apply my-changes.patch. Patches are still useful today: sharing code changes via email, applying security updates, backporting fixes across branches, or when the original repository isn't accessible. Patch files include metadata like filenames, line numbers, and sometimes author info. They're plain text so they work across different systems and can be reviewed before applying. Always test patches on a copy first since they directly modify files.

Three-Way Merge and Conflict Resolution

When merging branches, git performs a three-way merge using three versions: base (common ancestor), ours (current branch), and theirs (branch being merged). If the same line changed in both branches, a merge conflict occurs. Git marks conflicts with <<<<<<< HEAD (your changes), ======= (separator), and >>>>>>> branch-name (their changes). To resolve: manually edit the file to keep desired changes, remove conflict markers, then git add and git commit. Diff tools help here: git mergetool launches visual merge tools like KDiff3, Meld, or VS Code. These show three or four panes (base, ours, theirs, result) allowing you to pick changes. Some teams use git rerere (reuse recorded resolution) to automatically resolve recurring conflicts. Best practices: pull frequently to minimize divergence, make small commits to isolate conflicts, use feature flags instead of long-lived branches, and communicate with teammates when touching the same files. Understanding three-way merge explains why git is more powerful than simple file comparison.

Diff in Code Review Best Practices

Effective code review depends on clear diffs. **Keep Pull Requests Small** - reviews under 400 lines get 70% more thorough feedback. **Commit Logically** - each commit should be a single logical change, making diffs easier to understand. **Write Descriptive Commit Messages** - explain why, not what (the diff shows what). **Use Draft PRs** - for work-in-progress, preventing premature reviews. **Review Your Own Diff First** - before requesting review, check your diff for debug logs, commented code, or unintended changes. **Ignore Whitespace in Reviews** - GitHub allows '?w=1' in URL to hide whitespace changes. **Review Line by Line** - don't just scan for red flags, understand each change. **Ask Questions, Don't Command** - 'Could we extract this into a function?' is better than 'Extract this.' **Approve With Minor Nits** - if changes are trivial, approve and trust the author to fix. **Use Suggest Feature** - GitHub/GitLab allow suggesting code changes inline. These practices reduce review time while maintaining quality.

Diff Tools in Different Editors

Most modern editors have built-in diff capabilities. **VS Code**: File → Compare Active File With... or select two files and right-click → Compare Selected. Inline diff view with CodeLens, minimap showing change locations, and three-way merge UI for conflicts. Install GitLens extension for advanced git diff features. **IntelliJ IDEA/WebStorm**: VCS → Show Diff or Ctrl+D on selected files. Powerful three-way merge tool, local history diff, and 'Compare with Branch' feature. **Sublime Text**: Install FileDiffs package, then Tools → FileDiffs → Diff File With Tab. **Vim**: Use vimdiff command or :diffthis in two split windows. Navigate with ]c (next change) and [c (prev change). **Emacs**: M-x ediff-buffers or M-x ediff-files. **Visual Studio**: Team Explorer → Changes → View Diff or right-click file. For command-line lovers, tools like diff, git diff, colordiff (colored output), or diff-so-fancy (improved git diff) work great in terminals. Choose tools that integrate with your workflow.

Binary File Comparison

While diff tools work on text, binary files (images, PDFs, compiled code) need specialized tools. **Images**: Use image diff tools like ImageMagick's compare command or GitHub's image diff feature which shows swipe, onion skin, or difference overlays. Perceptual diff tools like perceptualdiff or pixelmatch detect visual changes humans would notice. **PDFs**: Tools like diff-pdf or Adobe Acrobat Compare Documents highlight text and layout changes. For developers, convert PDF to text first (pdftotext) then diff the text. **Excel/Spreadsheets**: xltrail, Spreadsheet Compare (Microsoft), or convert to CSV and diff. **Databases**: SQL schema comparison tools (Red Gate SQL Compare, Liquibase), or export to SQL and diff. **Zip/Archives**: Archive diff tools like 7zip's compare or extract both and diff contents. **Binary Executables**: Binary diff tools (bsdiff, xdelta) create binary patches, but for code review, decompile first. The key insight: convert non-text formats to comparable text representations when possible, or use domain-specific diff tools.