Merge CSV Files

1. 1

   Add files

   Add two or more CSV, TSV or PSV files by picker or drag and drop. Each file is read and its delimiter and encoding detected separately.

2. 2

   Order them

   Move files up or down. The merge follows the list from top to bottom, and the first file supplies the header.

3. 3

   Choose how columns line up

   Match columns by their header names, append them by position, keep only the columns every file shares, or switch to a key join.

4. 4

   Set the options

   Choose the header mode, whether to de-duplicate rows, whether to add a source-file column, and the output format.

5. 5

   Merge

   Combine the files into one table and check the preview, which shows the merged header and the first rows.

6. 6

   Preview and export

   Download as CSV, TSV, JSON or NDJSON, or copy the output to the clipboard.

Combine several delimited files into one table, with control over how the columns line up and what happens to rows that repeat.

• Merge multiple files — Combine up to five CSV, TSV or PSV files into a single output on the free plan, and up to a hundred with Pro.
• Match columns by name — Line up columns on their headers so files that list the same fields in a different order still merge correctly.
• Join on a key column — Attach a lookup table to an export on a shared column, keeping every row, only matched rows, or only unmatched ones.
• Delimiter control — Comma, semicolon, tab and pipe are detected per file, and any file can be overridden on its own.
• Encoding options — Read files as UTF-8, UTF-16, Windows-1252 or true ISO-8859-1, with byte-order-mark detection.
• Header handling — Use the first file's header once, keep every file's header inline, or treat every row as data.
• Duplicate removal — Drop repeated rows on the whole row or on the columns you nominate, and see how many went.
• Preview and export — Review the merged table as a grid or as raw text, then download as CSV, TSV, JSON or NDJSON, or copy it.

This is the setting that decides whether a merge is correct, and it is the one most online mergers get wrong. Three modes cover the cases that actually occur.

• Match by name — The default. Every column any file has appears once, in the order it was first seen, and each value lands under its own heading. Header names are compared without regard to case or surrounding spaces, so Email, email and "email " are one column.
• Append by position — Rows are appended left to right, using the first file's header. This is the right choice for headerless fragments of one table, and the wrong choice for exports from different systems - which is why it is a deliberate selection rather than the default.
• Only shared columns — Keeps just the columns present in every file, so the output has no blank cells. If the files share no column names at all, the merge stops and says so rather than writing a file of empty rows.

Rows that are wider than the header

• Nothing is discarded — A row with more cells than its file has headers gets extra columns named Column 4, Column 5 and so on, so a ragged export loses no data on the way through.
• Repeated headers stay separate — A file whose header lists the same name twice keeps both columns; collapsing them onto one name would silently drop a column of data.
• Short rows are padded — A row with fewer cells than the header is filled out with blanks rather than shifting the values that follow it into the wrong columns.

Stacking files answers "put these tables end to end". A key join answers a different question: "add the columns from this lookup table to the rows in that export". The first file in the list is the base, and every later file is joined onto it in turn.

• Left — Every row of the first file is kept, and the matching columns from the other files are added beside it. Rows with no match get blanks, so nothing disappears.
• Inner — Only rows that match are kept. Use it when a row without a counterpart is not a row you want in the result.
• Unmatched only — Keeps just the rows of the first file that have no counterpart. This is how you find the customers with no orders, or the ids that a second export is missing.
• One match or every match — When a key repeats on the right, choose whether to take the first match - which keeps the output the same height as the base table - or emit one row per match, which is what a database join does.
• The multiplicity is always reported — However you set it, the number of base rows that matched more than once is shown above the preview, so a join can never quietly drop rows or quietly multiply them.
• Colliding column names are kept apart — If a file being joined in has a column the base already has, it arrives named after the file it came from rather than overwriting what was there.

What the first row of each file means is a property of your files, not of the tool, so it is a setting rather than a guess.

• First row as header — Every file has a header; the merged file carries one, taken from the first file. The header rows of later files are used to line the columns up and are then dropped.
• Keep every header — Each later file's header row is also written into the body, so a reader can see where each file's rows begin. Useful when the files are genuinely different tables that you want in one document.
• No header — Every row is data and the columns are named by position. Column matching becomes positional, because there are no names to match on.
• Source file column — Adds a column naming the file each row came from. Without it, a merged file cannot be audited: there is no way to tell which of five exports a suspect row came from.
• It never overwrites a real column — If your data already has a column with the name you chose, the source column is given a distinct name instead of silently replacing it.

Merging monthly exports whose windows overlap is the ordinary case for this, and it is why de-duplication belongs in the merge rather than in a second pass.

• Whole row — Two rows are duplicates only when every column matches. This is the safe default and it never removes a row you would have wanted.
• Chosen columns — Nominate the columns that identify a record - an order id, or an id and a date - and rows agreeing on those are treated as the same record.
• The first occurrence wins — Rows are kept in merge order, so the copy from the earliest file in the list is the one that survives.
• The count is shown — The number of rows removed appears above the preview. A de-duplication that silently changed the row count would be indistinguishable from a bug.

These settings control parsing and the structure of the merged output.

• Delimiter — Auto, comma, semicolon, tab, or pipe - set globally at intake and overridable on any single file.
• Encoding — Choose the reading encoding per file, or leave it on auto and let the tool decide from the bytes.
• First row as header — Use the first file's header once in the merged output.
• Column mapping — Rename a column before it is written, or drop it from the output entirely, without editing any of the source files.
• Output name — Set the file name the download is saved under. The extension follows the output format you picked.

Leave it on Auto first; switch to a specific delimiter if a file parses into one column or the row widths look uneven.

• Comma — Most common in CSV exports, and the format's namesake.
• Semicolon — What Excel writes in locales where the comma is the decimal separator - most of continental Europe.
• Tab — For TSV-like files, and the safest choice when the data itself is full of commas.
• Pipe — Used in some data pipelines and mainframe exports, because it almost never occurs inside a value.
• Detection is per file, and it parses — Each file is scored by parsing a sample with each candidate and measuring how rectangular the result is, rather than by counting separators in the first line - a method that a quoted address containing a comma defeats immediately.

Mojibake in a merged file almost always comes from one file being read with the wrong encoding, so encoding is chosen per file and the file's own declaration wins.

• The mark overrides the dropdown — A byte-order mark is the file stating its own encoding; a dropdown is a guess. When a file declares itself, the declaration wins and the tool says so beside that file.
• UTF-8 with a mark — What Excel's own "CSV UTF-8" export writes. The mark is metadata, so it is stripped rather than left in the first heading, where it silently breaks every later match on that column.
• UTF-16 — What Excel's "Unicode Text" export produces. Read as UTF-8 it becomes a wall of empty characters and one enormous single-column row, so it is detected rather than assumed.
• Windows-1252 and ISO-8859-1 are different here — Most tools treat them as the same decoder because the web standard does. This one implements real ISO-8859-1 as well, so a file where byte 0x92 is a control character rather than a curly apostrophe reads correctly.
• Writing a mark on the way out — Turn the byte-order mark on when the merged file is going into Excel on Windows, which otherwise opens a UTF-8 file as the system code page and turns every accented name to nonsense.

The merged table is one thing; how it is written is another, and the destination usually decides.

• CSV — The default, with your choice of output delimiter. Fields are quoted only when leaving them bare would change what a reader sees.
• TSV — Tab-separated, for pasting straight into a spreadsheet or for tools that dislike quoting.
• JSON — An array of objects keyed by the header. Duplicate headings are made distinct first, because an object cannot hold the same key twice and the second would overwrite the first.
• NDJSON — One object per line, which is what log pipelines and streaming importers expect.
• Line endings — Auto follows the first file, or force LF or CRLF. Writing LF unconditionally is why some merged files open in Windows editors as one very long line.
• Quote every field — Off by default. Turn it on for importers that require it; it never changes what the file means, only how it looks.

A single merged file is easier for analysis, import pipelines, and sharing.

• Simpler analysis — Use one combined file in spreadsheets and scripts instead of opening a folder of exports one at a time.
• Cleaner imports — Many tools accept one CSV more easily than many files, and some accept only one.
• One period from monthly exports — Twelve monthly reports become one year, and with de-duplication on, the overlapping days at each boundary sort themselves out.
• Lookup data attached once — A key join writes the customer name next to the order id once, instead of a spreadsheet formula that has to be maintained.

Each file is read and parsed on its own, then the parsed tables are combined in list order.

• Load files — Add CSV files by picker or drag-and-drop. Each file is read in pieces rather than all at once, so a large set does not have to fit in memory twice.
• Detect and parse — The delimiter, quote character and encoding are detected per file, and the rows are parsed once and kept.
• Apply options — Changing a setting re-combines the rows that are already parsed, so the preview keeps up without re-reading a single file.
• Build output — Columns are resolved once, then every row is filled by direct lookup, which is what keeps a half-million-row merge to a fraction of a second.
• Preview and export — The merged table is shown before you export, then written in blocks straight to a download rather than assembled into one enormous string.

Merging runs off the main thread, so the page stays responsive while a large set is combined.

• CSV Split
• CSV to Excel
• CSV Viewer
• CSV Tools
• Clean up repeated rows

  A second pass over a merge whose sources overlapped more than de-duplication caught

• Sort the combined file

  Merging preserves list order; sort by a column once the rows are together