Join CSV files

Join CSV files combines records horizontally by a key you select. A product table might contain SKU and Name while a supplier lookup contains Product ID and Delivery Region. A join can place the related fields together even when the two identifier columns have different names. The relationship comes from their values and your field selection, not from a guessed interpretation of column labels. If you only need to append all records below one another, use the separate merge tool.

Import and confirm the primary table A and supplementary table B. Select the matching fields on each side in corresponding order. For a composite key, the first selected field on A corresponds to the first selected field on B, and so on. The number of selected components must match. Use all the components needed to identify the relationship: joining on SKU alone can be too broad if the real identity is SKU together with Region or Version.

Keep every record from A produces a result for every primary record, adding fields from B when a match exists. For an A record without a match, the B fields are missing. This is appropriate when A defines the population you must retain, such as all products in a catalog, and B supplies optional attributes. It does not mean every primary record was successfully matched. Inspect the unmatched A report to see the remaining gaps.

Only records matching on both sides excludes unmatched records from the joined table. It can answer a question about the overlap between two datasets, but it deliberately reduces the population. Keep every record from both tables also includes B records with no matching A record, with missing A fields. The unmatched reports remain available independently of the main joined result. A missing match is a data relationship outcome, not a generic system failure or proof that a record is invalid.

Repeated keys can multiply records. If one key occurs twice in A and three times in B, all matching combinations produce six output rows for that key. This can be correct for some relationships and very wrong for others. The workbench computes the projected output size before running an accepted join and surfaces duplicate-key information. Many-to-many combinations require their own explicit allowance. You can instead return to the sources and resolve duplicates or choose a more specific composite key.

The first attempt shows a projection for review. Check the count, the selected keep mode, and the duplicate situation, then confirm the join and run again. If the projection exceeds the output record or cell limit, the operation remains blocked. Permission for all combinations does not bypass scale limits. The estimate includes the unmatched rows required by your selected mode, so it can be compared directly with the eventual output total. No duplicate match is resolved by choosing a random row.

Empty and missing key components do not match one another. Two records lacking a product identifier are not evidence of the same product. The string zero is a populated key, while a blank string is not. Ignore case and Trim surrounding whitespace are visible matching options; they are off by default. Enabling them changes the equality test but does not rewrite the values displayed in either source. Original values and source positions remain attached to the resulting records.

Columns from B are appended to A. If a name already exists, the B column receives a source suffix such as _B, with additional disambiguation if necessary. The workbench does not silently overwrite A's value, even if a similarly named B field contains a different value. Matching key columns from B are also retained, making it possible to inspect both original spellings. Review the final names before using the column mapper to create a destination-specific layout.

Suppose A has two rows for code 001, representing two catalog variants, and one row with no code. B has three rows for 001, representing three delivery regions, and one row with no code. Keeping every record from both tables projects eight rows: six valid combinations for 001, one unmatched A record, and one unmatched B record. The empty-key rows do not combine into one row merely because both are blank.

If you expected only one row per product, the six combinations reveal that the chosen key is not sufficient for that expectation. Stop and choose an additional field, reduce B to a single justified record per code, or change the task. If you actually need every variant and region combination, allow the many-to-many relationship and confirm the projection. The final count should then equal eight, and the unmatched reports should each contain one record. This explicit check prevents later totals from being inflated without notice.

The output summary separates matched combinations from records found only in A or only in B. Matched combinations are output rows, not necessarily a count of distinct entities. Duplicate-key reports identify repeated relationships, and source locations help trace each combination to its contributing records. Use the grid to inspect cases with suffixes, missing fields, and repeated keys. A search in the grid is a viewing aid; it does not change which combinations the join produced.

When exporting, choose the full result or an unmatched report deliberately. An archive can retain all supporting outputs together with a file list. CSV cannot distinguish every internal missing-value state, so missing join fields become empty fields on export. Spreadsheet protection may prefix formula-like values and reports the number affected. Verification rereads the generated text before a download is made. This checks serialization consistency; it does not certify that your selected keys represent the intended business relationship.