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.
Loading tool…
Browser-basedWhat 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.
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.
What you can do with this tool
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.
How to use
- 1
Paste the common base version in the first box.
- 2
Paste your version and the other branch's version in the next two.
- 3
Review row classifications, counts, and the merged preview for one-sided and identical edits.
- 4
Resolve every conflict marker manually and rerun the real version-control merge before committing.
Use 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
Using a guessed or already-modified base changes every classification. Retrieve the actual common ancestor before trusting the comparison.
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.
The merged preview is a review aid. Resolve markers, run the real merge, execute tests, and inspect syntax or schema validity before saving.
FAQ
Does 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.
Useful next steps
Open a nearby browser tool when you need to validate, convert, or reuse the result.