CSV to SQL Converter

A customer export lands as a CSV and the staging table expects INSERT statements, or you are seeding a demo database from a spreadsheet someone already maintains. Hand-writing inserts for a hundred rows is how apostrophes and type mismatches sneak into production scripts. This converter parses RFC 4180 CSV in the browser, infers a column type per field, and emits a CREATE TABLE plus multi-row batched INSERTs tuned to your SQL dialect.

Paste the data, pick PostgreSQL, MySQL, SQLite, or SQL Server, and copy or download the result. Type inference, identifier sanitization, and quote escaping all happen locally, so real exports never leave the machine.

How the conversion pipeline works

The parser is a single-pass state machine over the raw text. It tracks whether it is inside a quoted field, treats doubled double-quotes as a literal quote character, and splits on the chosen delimiter only at the top level, so a comma inside a quoted name never becomes a column break. Carriage returns are swallowed and line feeds advance the row counter, which keeps Windows-exported files from producing empty trailing rows.

Header names are sanitized into safe identifiers: characters outside A-Z, a-z, 0-9, and underscore become underscores, a leading digit gains a c_ prefix, and duplicates are renamed with a numeric suffix while a warning records the change. The same names are then quoted with the dialect-appropriate wrapper (double quotes, backticks, or brackets) in both the CREATE TABLE and every INSERT column list.

Values are cast per inferred type: numbers are emitted bare, booleans become TRUE/FALSE (or 1/0 for MySQL and SQLite), dates and timestamps stay quoted strings, and everything else is quote-escaped for the target dialect. Rows accumulate into multi-row VALUES clauses until the batch size is reached, then a fresh INSERT statement begins, ending with a semicolon.

Before and after: a three-row export

Input — customers.csv with mixed types and an apostrophe:

id,name,email,active,signup_date
1,Alice Johnson,alice@example.com,true,2024-01-15
2,Bob O'Brien,bob@example.com,false,2024-03-01
3,Carol "CJ" Nguyen,carol@example.com,true,2024-07-04

Output — PostgreSQL dialect, CREATE + INSERT:

CREATE TABLE "customers" (
  "id" INTEGER,
  "name" TEXT,
  "email" TEXT,
  "active" BOOLEAN,
  "signup_date" DATE
);

INSERT INTO "customers" ("id", "name", "email", "active", "signup_date") VALUES
  (1, 'Alice Johnson', 'alice@example.com', TRUE, '2024-01-15'),
  (2, 'Bob O''Brien', 'bob@example.com', FALSE, '2024-03-01'),
  (3, 'Carol "CJ" Nguyen', 'carol@example.com', TRUE, '2024-07-04');

Who converts CSV to SQL

Common mistakes when loading CSV into databases

• Assuming every apostrophe is already escaped. A name like O'Brien breaks any script that concatenates strings without doubling the quote. This converter escapes per dialect automatically; if you hand-edit the output, keep the doubling intact.
• Letting Excel reformat identifiers and dates. Exported-from-spreadsheet CSV often turns 1-800 numbers into scientific notation and dates into the locale format. Check the inferred column list here before assuming the data survived the round trip through Excel.
• Issuing one INSERT per row against a remote server. A thousand single-row inserts can take minutes over a high-latency connection. Raise or lower the batch size here until statement length sits comfortably under your server's max_allowed_packet or similar limit.
• Trusting empty string and NULL interchangeably. An empty cell loaded as '' will not match WHERE col IS NULL later. Decide per dataset whether blanks mean missing or empty, and set the NULL toggle accordingly before generating the script.

Best practices for CSV imports

• 1.Generate into a staging table first, validate row counts and spot-check rows, then promote with an INSERT INTO target SELECT FROM staging statement inside a transaction.
• 2.Pin explicit column lists in every INSERT, which this tool already emits, so a later schema change does not silently shift positional values into the wrong fields.
• 3.Keep the batch size aligned with your database packet limit; 200 rows is a safe default for most managed PostgreSQL and MySQL instances and can be raised for bulk warehouse loads.
• 4.Store the generated .sql alongside the source .csv in version control so the exact transformation used for a load is auditable months later.

Frequently asked questions