Three-Way Diff Viewer
Paste a base version plus two edits and see conflicts, one-sided changes, and auto-merge candidates.
Tool code processes selected files and entered content in your browser and does not submit them to a TOOLGRID processing endpoint. TOOLGRID measures tool usage, not the content you enter.
- No TOOLGRID input upload
- No account
- Review before copy
Loading tool…
What this tool does
Compare a common base with versions A and B by line index, classify one-sided, identical, unchanged, and conflicting edits, and produce a reviewable merged preview with familiar conflict markers. This is deterministic visual triage, not a replacement for Git's sequence-aware merge algorithm.
Three-Way Diff Viewer places a common base beside versions A and B and classifies every aligned row as unchanged, changed in A, changed in B, changed identically, or conflicting.
A one-sided edit is selected automatically, the same edit on both sides is kept once, and incompatible edits receive <<<<<<< A, =======, and >>>>>>> B markers in the merged preview.
Alignment is by line number rather than longest-common-subsequence matching. Insertions or deletions can shift later rows and create apparent conflicts, so confirm the final merge with Git or another sequence-aware tool.
Where this tool earns its place
Compare a known base with two short configuration edits to see which lines are safe to select and which require a decision.
Explain how two people changed the same policy, copy block, or code snippet before creating a final combined version.
Generate a compact example of one-sided, identical, and conflicting line changes for a ticket, lesson, or merge discussion.
What to check before relying on the result
- Performance and maximum practical input size depend on browser memory, device speed, and the structure of the input.
- Review the generated result before replacing or publishing an original file.
Open a nearby browser tool when you need to validate, convert, or reuse the result.
How to use
01Use Cases
Compare a known base with two short configuration edits to see which lines are safe to select and which require a decision.
Explain how two people changed the same policy, copy block, or code snippet before creating a final combined version.
Generate a compact example of one-sided, identical, and conflicting line changes for a ticket, lesson, or merge discussion.
Tips & Tricks
- 01Start from the exact shared base
Using a guessed or already-modified base changes every classification. Retrieve the actual common ancestor before trusting the comparison.
- 02Watch for shifted lines
Because rows align by index, inserting one line near the top can make many later rows appear changed. Keep samples short or align structural insertions manually first.
- 03Do not commit conflict markers blindly
The merged preview is a review aid. Resolve markers, run the real merge, execute tests, and inspect syntax or schema validity before saving.
FAQ
02Does it work like git merge?
It aligns lines by index for clarity. Real git merges use LCS with insertion/deletion — use this for quick visual triage, not a full merge replacement.
How are conflicts marked?
Conflicts appear with <<<<<<< A / ======= / >>>>>>> B markers in the merged output, matching the familiar git format.
Does it store my text?
The comparison runs in this browser tab. Tool code processes selected files and entered content in your browser and does not submit them to a TOOLGRID processing endpoint.
What happens when a line is inserted or deleted?
Rows are compared by index, so an insertion or deletion can shift subsequent lines and create extra apparent changes. A sequence-aware diff should verify structural edits.
Why is the common base important?
The base establishes whether A, B, both, or neither changed each row. Using the wrong ancestor can turn safe one-sided edits into false conflicts or hide a real conflict.