Diff Checker — Compare Two Texts and Find Differences
A diff checker (difference checker) compares two pieces of text and highlights exactly what has changed — which lines were added, which were removed, and which are unchanged. Developers use diffs to review code changes; legal and business teams use them to compare document versions; writers use them to track edits. The free diff checker on PublicSoftTools shows line-by-line and character-level differences instantly.
How to Use the Diff Checker
- Open the diff checker.
- Paste the original text in the left panel (or "Version A").
- Paste the new or modified text in the right panel (or "Version B").
- Click Compare (or the comparison is live-updating as you type).
- Added lines are highlighted in green; removed lines in red; unchanged lines in neutral.
- Switch between line diff, word diff, and character diff modes for different granularity levels.
Types of Diff Comparison
| Diff type | How it compares | What is shown | Best for |
|---|---|---|---|
| Line diff | Compares text line by line | Added lines (green), removed lines (red), unchanged lines (neutral) | Code comparison, document revision, configuration file changes, log analysis |
| Word diff | Compares text word by word within lines | Individual words added or removed highlighted within each line | Document editing, identifying specific wording changes in long paragraphs |
| Character diff | Compares character by character | Individual characters changed highlighted within words | Finding subtle differences — an extra space, a changed digit, a transposed letter |
| Side-by-side diff | Shows original and new version in parallel panels | Two-panel view with corresponding sections aligned | Visual comparison of longer texts; easier to read than unified diff |
| Unified diff | Shows changes in a single panel with +/− symbols | + prefix for added, − prefix for removed, context lines unchanged | git diff output format; patch files; code review tools |
Common Use Cases
| Scenario | What you are comparing | Benefit |
|---|---|---|
| Code review | Comparing the old version of a function with the new version | See exactly which lines changed — spot unintentional modifications alongside intentional ones |
| Document revision | Contract v1 vs. contract v2 — find every change between versions | Legal review requires knowing every difference; line-level diff shows additions and removals clearly |
| Configuration file debugging | Working config vs. broken config — why did it stop working? | Immediately identifies the difference — which line changed, was added, or was removed |
| Plagiarism detection | Original text vs. submitted text — find unchanged copied sections | Unchanged lines between two documents reveal directly copied content |
| Data comparison | Export from two dates — what data changed? | CSV or JSON diff shows which rows were added, removed, or modified |
| API response monitoring | Yesterday's API response vs. today's — did anything change? | Detects breaking changes or unexpected data mutations in external APIs |
How the Diff Algorithm Works
The standard algorithm for computing diffs is the Longest Common Subsequence (LCS) algorithm, or the more efficient Myers diff algorithm (used in git and most modern diff tools). The algorithm:
- Finds the longest common subsequence — the longest sequence of lines (or words, or characters) that appear in both texts in the same order
- Anything in the original that is not in the LCS is a deletion (shown in red)
- Anything in the new text that is not in the LCS is an addition (shown in green)
- The LCS itself represents unchanged content
The Myers algorithm is optimised for the common case where differences are small — it finds the minimum edit distance (smallest number of insertions and deletions needed to transform one text into the other). This produces the most "human readable" diff — grouping changes together rather than scattering them randomly.
Reading a Unified Diff
The unified diff format (used by git diff, patch files, and code review tools) shows changes with the following conventions:
- --- a/filename — the original file (a/ prefix is git convention)
- +++ b/filename — the new file
- @@ −5,7 +5,8 @@ — hunk header: shows line numbers in the original (−5,7 = starting at line 5, 7 lines shown) and new file (+5,8 = starting at line 5, 8 lines shown)
- − line — line present in original but removed in new version
- + line — line present in new version but not in original
- line (two spaces) — context line: unchanged, shown for reference
Git Diff: The Developer's Diff Tool
Git provides built-in diff functionality. Key commands:
- git diff — shows unstaged changes (working directory vs. last commit)
- git diff --staged — shows staged changes (what would be committed)
- git diff HEAD~1 — shows changes from the previous commit
- git diff branch1 branch2 — shows differences between two branches
- git diff file.txt — shows changes in a specific file
GitHub, GitLab, and Bitbucket display diffs in pull request (PR) and merge request reviews, with visual highlighting of additions and deletions. Code review is fundamentally based on reading diffs to understand what changed between versions.
Diff for Non-Code Uses
Diff checkers are not only for code. Common non-developer uses:
- Legal documents: Contract redlining (comparing negotiated versions), regulatory document changes, terms of service updates
- Academic writing: Comparing draft versions of a paper; tracking supervisor's edits
- Journalism and fact-checking: Comparing official documents to previous versions to spot quietly changed text
- Website monitoring: Comparing page HTML over time to detect content changes
- Data validation: Comparing CSV exports from two dates to find changed or missing records
Whitespace and Case Sensitivity
Diff tools often have options for ignoring:
- Trailing whitespace: Extra spaces at line ends — common when copying text from different editors or operating systems
- Leading whitespace (indentation): Useful when comparing code reformatted with different indentation styles
- Blank lines: Ignoring added/removed empty lines to focus on content changes
- Case differences: Treating "Hello" and "hello" as equal
- Line endings: Windows (CRLF) vs. Unix (LF) line endings often cause every line to appear different — ignore line endings to see only content changes
Common Questions
What does a "merge conflict" look like in a diff?
A merge conflict occurs when two branches in git both modified the same lines in different ways. Git marks the conflicted area with conflict markers: <<<<<<< HEAD shows the current branch version; >>>>>>> branch-name shows the incoming branch version; ======= separates them. The developer must manually edit the file to choose or combine the versions, then remove the conflict markers. Diff checkers can help visualise the two conflicting versions before resolving.
Can I compare binary files with a diff checker?
Text-based diff checkers work with UTF-8 text — source code, JSON, XML, CSV, HTML, markdown. Binary files (images, PDFs, compiled executables, Word .docx) cannot be compared meaningfully with a text diff. Word documents can be compared using Word's built-in track changes or by extracting their XML content first. Specialised tools handle binary diffs — images can be diffed pixel-by-pixel; database schemas have their own diff tools.
What is the difference between diff and patch?
A diff shows the differences between two texts. A patch is a file containing a diff that can be applied to transform one version into another. The classic Unix workflow: generate a diff with the diff command; distribute the patch file; recipients apply it with the patch command to update their local copy. Git patches (git format-patch, git apply) extend this for version-controlled workflows. Patch files allow changes to be distributed without sending entire files.
Compare Texts Side by Side
Paste two versions of any text to instantly see added, removed, and changed lines highlighted in green and red.
Open Diff Checker