Convert CSV to SQL INSERT statements
Seeding a dev database, moving a lookup table between environments, turning a client’s spreadsheet into rows — sometimes the most portable answer is still a .sql file of INSERT statements you can review in a diff and run anywhere. This converter writes them properly: identifiers double-quoted, embedded apostrophes escaped the SQL way (O'Brien → 'O''Brien'), empty cells as NULL, numbers unquoted, and values batched 500 rows per INSERT so the file loads fast without hitting statement-size limits.
It can also emit a CREATE TABLE with column types guessed from your data (NUMERIC for numeric columns, TEXT otherwise) — a starting point you’ll refine, not a schema designer. And since CSVs headed for databases are often the sensitive kind, it bears repeating: generation happens in your browser; nothing is uploaded.
Preset: the SQL export panel opens as soon as your file loads.
Drop a CSV, TSV or Excel file here
.csv · .tsv · .txt · .csv.gz · .xlsx — files up to 4 GB open here, in your browser. Nothing is uploaded; the file is read in place on your device.
Filters combine with AND. Use the search box for a quick any-column match. Regex filters use JavaScript syntax.
Untick to hide a column (hidden columns are left out of exports). Type to rename — renames apply to exports too.
Exports include your filters, sort, edits and cleanups. Hidden columns are left out; renamed headers apply. The file is generated on your device — nothing is sent anywhere.
How it works
- Drop the CSV. Headers become column names (rename any in the Columns panel — they’re quoted, so spaces survive, but your future self may prefer snake_case).
- Set the table name; tick CREATE TABLE if you want the scaffold.
- Download the .sql and review it — it’s plain text, made to be read.
- Run it: psql -f, sqlite3 < file, mysql < file (ANSI_QUOTES mode), or paste into any SQL console.
Dialect notes (the honest fine print)
The output is deliberately conservative ANSI SQL: double-quoted identifiers, single-quoted strings with doubled apostrophes, NULL for empties, multi-row VALUES lists. That runs unmodified on PostgreSQL and SQLite. MySQL/MariaDB default to backtick identifiers — either run SET sql_mode='ANSI_QUOTES' first (one line) or rename your columns to need no quoting. SQL Server accepts the strings but prefers [bracket] identifiers, and its multi-row VALUES caps at 1,000 rows — the 500-per-statement batching here stays under it.
For bulk loads past, say, a hundred thousand rows, INSERT scripts are the slow road — every database has a native bulk loader (Postgres COPY, MySQL LOAD DATA, SQLite .import, SQL Server BULK INSERT) that ingests raw CSV an order of magnitude faster. The INSERT file’s virtue is reviewability and portability, not speed; use it where those matter.
Good to know
- Type guessing samples your data: a column that’s numeric except one stray “n/a” becomes TEXT — clean the stray first (find & replace) if you want NUMERIC.
- Leading-zero values are quoted as strings even in typed mode — your ZIP codes arrive intact.
- Batches of 500 keep individual statements small enough to paste into any SQL console without truncation.
Frequently asked questions
Is the SQL safe against injection-style breakage from my data?
Values are escaped by doubling single quotes — the standard SQL literal escape — so apostrophes, commas and even semicolons inside your data can’t terminate a statement. As with any generated SQL, review the file before running it against anything that matters; it’s plain text precisely so you can.
Which databases can run the output directly?
PostgreSQL and SQLite as-is. MySQL/MariaDB with ANSI_QUOTES enabled (or unquoted-safe column names). SQL Server generally works; its VALUES-list limit is respected by the 500-row batches.
How are dates handled?
As quoted strings, exactly as they appear in the CSV — the converter doesn’t guess date formats. Databases parse ISO-style strings into DATE columns on insert; if your CSV has ambiguous formats like 03/04/2025, normalize them first (find & replace with regex works well).
Can it generate UPDATE or UPSERT statements?
No — INSERTs (optionally with CREATE TABLE) only. Upserts are too dialect-specific to generate honestly (ON CONFLICT vs ON DUPLICATE KEY vs MERGE); a common pattern is inserting into a staging table with this file, then merging with one hand-written statement.