Diff Checker
Compare text with line-level and word-level diff, collapsible sections, and patch export.
About Diff Checker
A diff (short for difference) is a structured comparison between two versions of text that identifies exactly what has been added, removed, or changed. The concept originates from the Unix `diff` utility, first released in 1974 as part of the Fifth Edition of Unix, which implemented an algorithm based on the longest common subsequence (LCS) problem to produce the minimal set of edits needed to transform one file into another. This foundational algorithm, refined by Eugene Myers in 1986 into an O(ND) approach optimized for small differences, remains the basis of modern diff tools including those used by Git, GitHub, and virtually every code review platform.
Diffs can operate at different levels of granularity. A line-level diff treats each line as an atomic unit and reports which lines were added, removed, or unchanged -- this is the default mode used by `git diff` and most code review tools, because source code is inherently line-oriented. A word-level or character-level diff breaks the comparison down further, highlighting exactly which words or characters within a line have changed. Word-level diffs are particularly useful for prose, documentation, and any content where a single line might contain a long paragraph and a line-level diff would mark the entire line as changed even if only one word was modified.
The unified diff format, signified by the `---` and `+++` header lines and `@@` hunk markers, has become the de facto standard for representing text differences. Each hunk shows a section of the file where changes occur, with context lines (prefixed by a space) surrounding the removed lines (prefixed by `-`) and added lines (prefixed by `+`). This format is used by patch files, Git commits, pull request diffs, and automated code review tools. Understanding how to read and produce unified diffs is a core skill for any developer working in a version-controlled codebase, and tools that visualize these diffs with syntax highlighting and side-by-side views make the review process faster and less error-prone.
How to Use the Diff Checker
- Paste the original (or older) version of the text into the left input panel. This serves as the base against which changes will be measured.
- Paste the modified (or newer) version of the text into the right input panel.
- Click the Compare button to generate the diff. The tool analyzes both inputs and highlights the differences using color-coded markers -- typically green for additions and red for removals.
- Toggle between unified view (interleaved changes in a single column) and side-by-side view (original and modified text in adjacent columns) to find the presentation that works best for the type of content you are comparing.
- Switch between line-level and word-level diff modes. Use line-level for source code comparisons and word-level for prose or documentation where changes are more granular.
- Review each changed section systematically. Added content, removed content, and unchanged context lines are clearly distinguished, making it easy to verify that only the intended changes are present.
- Copy the diff output or export it as a unified diff / patch file for sharing with teammates, including in pull request descriptions or bug reports.
Common Use Cases
Code Review and Pull Request Analysis
Before approving a pull request, reviewers need to understand every change being introduced. A diff checker highlights exactly which lines were added, removed, or modified, allowing reviewers to focus their attention on the meaningful changes rather than scanning entire files. This is especially valuable when a PR includes formatting changes alongside functional modifications -- word-level diffs can distinguish substantive edits from whitespace adjustments.
Configuration File Comparison
Comparing configuration files between environments (development, staging, production) is a common operational task. A diff checker reveals which settings differ, making it easy to spot missing environment variables, incorrect database connection strings, or feature flags that were enabled in staging but not yet promoted to production. This prevents the class of deployment bugs caused by configuration drift.
API Response Regression Testing
When refactoring backend services, developers need to verify that API responses remain unchanged. By capturing a response before and after the refactor and running them through a diff checker, any unintended changes in field names, data types, nesting structure, or values become immediately visible. This is a lightweight form of contract testing that catches regressions before they reach integration tests.
Documentation and Content Versioning
Technical writers and content managers use diff checking to review revisions to documentation, policy documents, and release notes. Word-level diffs are particularly valuable here, as they pinpoint exactly which sentences or phrases were modified within a paragraph, making editorial review far more efficient than manually comparing two versions of a long document side by side.
Frequently Asked Questions
What is the difference between a line-level diff and a word-level diff?
A line-level diff treats each line as an indivisible unit: if any character on a line changes, the entire line is marked as removed and the new version is marked as added. This works well for code where each line typically contains a single statement. A word-level diff further analyzes changed lines to identify exactly which words were modified, leaving unchanged words unmarked. This is much more useful for prose, Markdown, or any content where lines are long and changes are small.
What is the unified diff format?
The unified diff format is a standard text representation of differences between two files. It begins with header lines identifying the original and modified files, followed by one or more 'hunks' prefixed by @@ markers that indicate line numbers. Within each hunk, lines prefixed with a space are unchanged context, lines prefixed with '-' exist only in the original, and lines prefixed with '+' exist only in the modified version. This format is used by Git, patch files, and most code review tools.
How does the diff algorithm work?
Most diff tools use a variant of the Myers diff algorithm, which models the problem as finding the shortest edit script (the minimum number of insertions and deletions) to transform one sequence into another. This is equivalent to finding the longest common subsequence (LCS) between the two inputs. The Myers algorithm operates in O(ND) time, where N is the total length of both inputs and D is the number of differences, making it very efficient when changes are small relative to the total size -- which is the common case in version control.
Can I use the diff output as a patch file?
Yes. A unified diff is the same format used by patch files. You can save the diff output to a .patch or .diff file and apply it using the `patch` command or `git apply`. This is useful for sharing specific changes without sending entire files, creating hotfixes that can be applied to multiple branches, or documenting exactly what was changed in a bug fix for audit purposes.
Why do some diffs show lines as changed when only whitespace is different?
By default, most diff tools treat whitespace as significant, so a change from spaces to tabs, added trailing whitespace, or different line endings (CRLF vs LF) will all be reported as modifications. Many diff tools offer an option to ignore whitespace changes, which is useful when comparing files across different editors or operating systems. In code review, however, whitespace changes can be meaningful (for example, in Python where indentation affects semantics), so this option should be used judiciously.
What does 'context lines' mean in a diff?
Context lines are the unchanged lines shown before and after each changed section in a diff. They serve two purposes: they help the reader orient themselves in the file by showing surrounding code, and they provide the `patch` utility with enough information to locate the correct position for applying changes even if line numbers have shifted. Git diffs typically show 3 context lines above and below each change, though this is configurable with the -U flag.