Don't like ads? Go Ad-Free Today 

3-Way Text Diff & Merge Viewer

DeveloperText

ADVERTISEMENT · REMOVE?

[iotools_3_way_text_diff_merge_viewer]

ADVERTISEMENT · REMOVE?

Guide

3-Way Text Diff & Merge Viewer

Paste a base version plus two divergent versions (A and B) and the tool produces a merged result using the classic diff3 algorithm. Lines that only one side changed are merged automatically; lines both sides changed differently are flagged as conflicts you can resolve by clicking Accept A, Accept B, Keep Base, or combine both — all client-side, no upload required.

How to Use

Paste the original (base) text into the Base box. This is the common ancestor both versions started from.
Paste the first edited copy into Version A and the second edited copy into Version B.
Pick a default On Conflict strategy (show markers, prefer A, prefer B, or keep base).
Review the merged output: green-bordered OK chunks are auto-merged; orange-bordered Conflict chunks show all three sides and need a decision.
For each conflict, click Accept A, Accept B, Keep Base, or Both to lock in your choice. Use Clear to undo.
Copy or download the resulting Merged Text when you are done.

Features

Real diff3 merge – LCS-based line matching identifies stable anchors shared by all three inputs and groups the changes between them.
Per-conflict resolution – every conflict is rendered as a side-by-side view of A, Base, and B with one-click acceptance.
Combine both sides – pick “Both (A then B)” or “Both (B then A)” when you want the union of two edits instead of choosing one.
Standard conflict markers – the plain output uses the familiar <<<<<<< / ||||||| / ======= / >>>>>>> markers so the result is friendly to Git tooling.
Default strategies – set “Prefer A”, “Prefer B”, or “Keep Base” to auto-resolve every conflict the same way without clicking each one.
Stays in your browser – no server round-trip, no upload; safe for source code, drafts, or any confidential text.

Why a 3-Way Merge?

A 2-way diff can only tell you that two texts differ — it cannot tell you which side intentionally changed something. A 3-way merge introduces a shared starting point (the base) and uses the difference from that anchor to decide intent. If only one side changed a line, the merge can take that change automatically. If both sides changed the same region in different ways, the merge correctly surfaces a conflict instead of silently dropping one author’s work.

ADVERTISEMENT · REMOVE?

 FAQ

What is the diff3 algorithm?

Diff3 is the canonical 3-way merge algorithm. It computes the longest common subsequence between the base and each variant, then walks the shared anchor points to classify the regions in between. Regions where only one variant differs from the base are applied automatically; regions where both variants differ from the base in incompatible ways become conflicts. It powers Git's classic merge strategy and the GNU diff3 utility.
How does an LCS-based diff work?

Longest Common Subsequence (LCS) is the longest sequence of lines that appears in both inputs in the same order, allowing gaps. A standard dynamic-programming table computes its length in O(m*n) time. Backtracking through the table yields the matching line pairs, and everything outside those pairs is treated as either an insertion or deletion. LCS gives a minimal, intuitive set of edits without requiring exact alignment.
Why are some changes auto-merged while others become conflicts?

During a 3-way merge the algorithm compares each gap between shared anchors three ways: base vs A, base vs B, and A vs B. If only one side differs from the base, the change is unambiguous and is taken automatically. If both sides made identical changes, the merge keeps one copy. Only when both sides changed the region differently does the merge raise a conflict, because there is no automatic way to honor both intents at once.
What do the <<<<<<<, |||||||, =======, and >>>>>>> markers mean?

These markers come from Git's diff3-style conflict format. The block between <<<<<<< and ||||||| shows version A, the block between ||||||| and ======= shows the common base, and the block between ======= and >>>>>>> shows version B. Seeing the original base alongside both edits makes it easier to decide which side to keep or how to combine them.
Is line-based merging different from character-based or word-based merging?

Yes. A line-based merge treats each line as the smallest atomic unit, which matches how source code, configuration files, and most plain-text documents are written. Character or word merging can produce finer-grained edits but tends to create noisy, hard-to-resolve conflicts in prose with reflowed text. Line-based merging is the standard choice for tools that mirror Git's behavior.