CSV to SQL INSERT

How the conversion actually works

The engine parses your CSV by RFC 4180's actual rules — records, fields, doubled quotes inside quoted fields, CRLF or LF endings — then treats the first record as the header and every later record as one row of the INSERT. Typing is applied per cell, immediately before emission:

Two details from real spreadsheet exports are handled rather than suffered: a UTF-8 byte-order mark at the start of the file, which Excel adds by default, is stripped before parsing, and the table name you type into the tool's table field becomes the quoted identifier in the INSERT — the example below uses products.

• Numbers: a cell matching an integer or decimal pattern is emitted bare — 42 and 24.99 become numbers. A leading zero disqualifies it, so 02134 stays a string and your postcodes survive.
• Booleans: true or false, in any casing, becomes TRUE or FALSE.
• Empty cells: an empty field becomes NULL. A field that is present but quoted-empty ("") stays an empty string, because RFC 4180 distinguishes the two and so does SQL.
• Strings: everything else is single-quoted with embedded quotes doubled — O'Brien becomes 'O''Brien'.
• Identifiers: header names are emitted as double-quoted column names, in header order.

The cell-to-literal mapping

One line per rule, so you can predict the output before you run it. Note that the empty cell and the quoted-empty cell are deliberately different rows of this table, because they are the pair people ask about most:

What the output looks like

The worked example below is the exact pair the converter's Load sample button produces for a table named products. Three rows, each exercising one rule: the desk lamp's price is a bare decimal and its stock flag a bare TRUE; the tent row needed RFC 4180 quoting in the CSV because the product name contains a comma, and the emitted SQL doubles its apostrophe; the lantern row leaves two cells empty and both land as NULL, not as empty strings. Save the output as a .sql file and it runs as-is in psql, sqlite3 or any migration runner — the statement is complete and semicolon-terminated.

Ragged rows and other honest refusals

RFC 4180 technically permits records with fewer or more fields than the header, but SQL does not — an INSERT tuple must fill exactly the columns its statement declares. So two inputs are refused with a message naming the line, rather than padded or truncated:

• A record whose field count differs from the header — padding with NULLs would invent values you never measured, and dropping extras would discard data you did provide.
• Duplicate header names — two columns with the same name cannot both be quoted identifiers in one INSERT, so the converter reports the column instead of silently renaming one of them.