Three-Way CSV Merge

A three-way CSV merge combines two independent sets of edits by comparing both with the same original table. The original is essential evidence: it tells the tool whether a value changed or merely remained unchanged. Upload the common base, edited A and edited B in their named roles. You may give the edited versions descriptive labels, but file timestamps and upload order do not establish which business value is authoritative. Without a reliable common base, use comparison to inspect differences rather than claiming that an automatic three-way result is justified.

This page is intended for returned spreadsheet copies, catalog reviews and other separate editing workflows. It is not a live collaboration service, a cloud version archive or a Git integration. Every source remains read-only. The tool creates a proposed combined table, exposes conflicts and produces a separate final copy only after the required decisions. It cannot infer that a renamed person or a changed identifier is actually the same entity.

Each role accepts CSV, TSV, pasted cells or an explicitly verified XLSX data region. Confirm encoding, delimiter and headers independently for each text file. For a workbook, select the sheet and data range and inspect the value mode, hidden content and cached formula results. The tool compares imported values and does not recalculate formulas or preserve complete workbook formatting. Identifiers such as 001 stay text. A preview shows a sample; full input checks occur before the merge.

Select one or more fields that uniquely identify records. The complete key must be present and unique in each version. Duplicate keys are blocking input errors, because choosing one of several rows would silently discard evidence. A blank key is also an error. Fix identifiers before deciding conflicts. The three versions must represent the same logical field set. Column order may differ, and a known renamed column can be mapped manually. Added or removed columns require explicit preparation in the column mapper; this version does not perform structural schema merging.

All non-key fields participate in exact text comparison. Spaces, case, empty strings, missing cells and literal NULL are not normalized into one value. If your task needs semantic normalization, perform and review that as a separate step on the source versions. Otherwise a normalization preference could conceal a real edit. A source row changing position does not count as a value change, and the output does not use row position to establish identity.

For each field, the tool compares the original, A and B values. When neither version changed it, the original remains. When only A changed it, the result uses A; when only B changed it, the result uses B. When both changed it to the same text, that common text is retained and recorded as an agreed change. Only different competing edits to the same field create a field conflict. There is no preference for the newest file or the longest-looking value.

Take record 001 with name Pen and price 10. A changes only price to 12. B changes only name to Marker. The combined record is 001, Marker, 12, with no field conflict. This is why selecting an entire winning file would lose useful work. If A changes price to 12 and B changes price to 13 instead, the price is unresolved. Other independent fields can still be understood, but the final download remains blocked until the conflicting price has been explicitly resolved.

An item added on only one side is retained. An item added on both sides under the same key is retained once when its complete values agree. Different additions under the same key are an addition conflict, requiring a record-level decision. These checks compare the full mapped row; they do not assume that a shared name means the records are interchangeable. The proposed result keeps surviving base records in base order, then appends new A records and finally new B records not already represented.

A base record removed by both editors becomes a proposed deletion. A record removed by one editor while the other leaves it unchanged is also a proposed deletion. Inspect the deletion list and its source references before confirming these removals together. If the surviving editor changed the record, removal competes with an edit and needs an individual delete-versus-edit decision. Selecting an absent side explicitly chooses deletion; keeping the base restores the original values for that conflict.

Changing a key is represented as deleting the old key and adding the new key. The tool does not track identity through fuzzy names or amounts. Review such pairs carefully before accepting a deletion. Even when every technical conflict is resolved, related business fields may still need validation: two independently valid edits can violate a rule when combined. Continue with the existing data validator when the result needs required-field, uniqueness or relationship checks.

Each conflict displays the original value, edited A, edited B and the final choice. Select A, B or the base explicitly, or enter a manual final value. Empty text is a valid manual field value and is different from leaving a conflict unresolved. A manual record-level resolution uses the displayed base column order and cannot change the identity key. For a deleted record, the absent marker is explanatory UI text; it is not written into your source data.

Conflict pages show twenty items at a time while the summary and export gate cover every conflict in the full input. Undo a particular choice by returning it to unresolved, or use the rule and review history controls. Confirming a choice recalculates the result against the same evidence. Changes to inputs, field mappings or comparison rules invalidate prior decisions. A saved rule file carries mappings and settings, but not conflict approvals or complete source tables; loading it requires a new run and fresh review.

The interface avoids an unreviewed button that simply overwrites every conflict with one side. That would conceal which fields and deletions were affected. A result with unresolved conflicts is visibly incomplete and cannot be exported as final. Conflict reports remain downloadable for investigation. Rows with unresolved conflicts are omitted from the candidate result rather than being filled silently with A or B. Treat the candidate row count as provisional until the blocking count reaches zero.

Once every conflict and proposed deletion is resolved, choose the complete result and download a new CSV or TSV. The export describes its exact tab, row count, encoding and headers. Preview search does not silently change that scope. The generated text is read again with the CSV parser and compared with the intended data. Spreadsheet formula protection may add prefixes to values; choose raw text separately only after reviewing the risk and the requirements of the receiving system.

Change summaries, deletion lists, conflict reports and detailed review records are separate tabs and separate downloads. Review records can include old values, competing values and source filenames, so they should not automatically accompany an externally shared final table. Source references use logical records, not physical text lines when cells contain newlines. Use the current-table action to continue with another tool only after the final result is unblocked.

Processing runs locally in a cancellable worker. Input size, cell count, output size and task time are bounded, and exceeding a limit stops processing instead of returning an unlabelled partial merge. Website loading still requests static resources, but file contents are not sent to a merge service. Site navigation can preserve the in-memory session; closing or refreshing clears it. Save any reviewed output you need before leaving, and retain your own original files as the evidence for later decisions.