CSV File Joiner

Join and merge two tabular CSV datasets using common relational keys with inner, left, right, and full outer joins

⚡ Sample Datasets:
Distinct Dataset Title

1. Relational Join Mode

2. Match Keys (Columns)

Table A Key
Table B Key

3. Upload or Paste Datasets

Table A (Left) - 4 Rows
Table B (Right) - 4 Rows
Null Placeholder
Duplicate Prefix
id name email country order_id customer_id product amount
1 Alice alice@example.com USA 101 1 Mechanical Keyboard 149.99
1 Alice alice@example.com USA 102 1 Wireless Mouse 49.50
2 Bob bob@example.com UK 103 2 USB-C Dock 89.00
3 Charlie charlie@example.com Canada NULL NULL NULL NULL
4 Diana diana@example.com Germany NULL NULL NULL NULL
Merged Records 5 Rows
Match Telemetry 2 Matches
Execution Model 100% Client-Side

Relational Algebra on Delimited Flat Files: The Architectural Foundations of Client-Side CSV Merging and Hash-Join Computation

In data engineering, operational analytics, and business intelligence, the Comma-Separated Values (CSV) specification formalized under RFC 4180 remains the universal lingua franca for tabular data transfer. However, raw tabular exports rarely exist as unified master tables. Data silos invariably fragment enterprise records: customer identities live in CRM exports, billing transactions reside in Stripe reports, and inventory counts sit in warehouse logistics logs. Recombining these disparate files typically forces data practitioners to spin up local Python pandas scripts, configure SQL staging schemas, or surrender proprietary spreadsheets to privacy-invasive third-party cloud SaaS converters.

Deconstructing Relational Join Types

Relational joins combine two flat datasets (Table A and Table B) by evaluating an equality condition (an equi-join) across specified match keys. The fundamental behavior of the output depends strictly on the join modality:

1. Inner Join (A ∩ B)

An Inner Join evaluates the strict intersection between both relations. Only records where the designated match key exists concurrently in both Table A and Table B appear in the compiled result set. Unmatched rows from either relation are discarded, ensuring zero null-padded rows in the output.

2. Left Outer Join (A ⟕ B)

The Left Outer Join retains every record from the left relation (Table A) without exception. If a corresponding record exists in Table B, its attributes are concatenated horizontally. If no match is found, the columns corresponding to Table B are filled with the designated null placeholder, preserving the integrity of Table A's population.

3. Right Outer Join (A ⟖ B)

The exact inverse of the Left Join. Every record from Table B is guaranteed to appear in the output. Where Table A has matching keys, its fields are populated; otherwise, Table A’s attributes are padded with null identifiers.

4. Full Outer Join (A ⟗ B)

A Full Outer Join computes the complete union of both datasets. It outputs all matching rows, followed by unmatched rows from Table A (padded with nulls for B's columns), and finally unmatched rows from Table B (padded with nulls for A's columns). This join is essential for reconciliation audits, such as comparing scheduled invoices against bank clearing ledgers.

Algorithmic Architecture: The In-Memory Hash Join

A naive approach to joining two tabular files uses a Nested Loop algorithm: iterating over every row in Table A and scanning every row in Table B. This results in a computational complexity of O(N × M), which freezes the browser UI when processing tables with thousands of lines.

Our engine implements an optimized two-phase Hash Join algorithm running in browser memory:

  1. The Build Phase: The engine scans Table B and extracts the designated join key from each row. It creates an in-memory hash multimap (Map<string, Row[]>) where each key maps to an array of matching rows, allowing seamless support for one-to-many (1:N) cardinality. This phase completes in linear O(M) time.
  2. The Probe Phase: The engine streams through Table A. For every row, it extracts the match key and performs an O(1) constant-time dictionary lookup against the pre-indexed hash multimap. Matching rows are combined immediately, while unmatched records are handled according to the selected join mode.

By utilizing hash indexing, overall time complexity drops to O(N + M), delivering near-instant execution across multi-megabyte datasets directly in client memory.

RFC 4180 Escaping & Column Collision Resolution

Merging flat files requires careful handling of schema anomalies:

  • Field Escaping: Values containing embedded commas, carriage returns, or double quotes must be wrapped in RFC 4180 quotes, with inner quotation marks doubled (e.g. "He said ""Hello""").
  • Header Name Clashes: When both tables share identical column names outside of the primary join key (such as status or created_at), our engine automatically applies an adjustable prefix (defaulting to b_) to Table B’s headers, preventing silent column overwrites in downstream applications.
  • Type Coercion and Normalization: Key mismatches caused by leading/trailing spaces or inconsistent casing (e.g., " SKU-10 " vs "sku-10") are mitigated via automated key trimming and case-normalization toggles.

100% Client-Side Confidentiality Standard

In compliance with enterprise privacy standards and GDPR requirements, your confidential datasets never leave your browser sandbox. File parsing, hash indexing, and CSV generation take place entirely in client-side memory using modern Web APIs. No customer records, proprietary financial ledgers, or telemetry logs are ever uploaded to an external server.

📊 Practical Merging Guideline

Always verify key cardinalities before merging large datasets. If Table B contains duplicate keys, each matching row from Table A will duplicate for every occurrence in Table B (producing a Cartesian product for that key). Use our Distinct Profile feature to save your join configurations to the local History Log for quick audits across revisions.