CSV to SQL

Turn CSV rows into SQL INSERT statements.

Table Name

CSV Input

or drop a file here

SQL Output

From CSV to SQL inserts

This tool reads the first CSV line as column names and emits one INSERT INTO statement per data row. Values are typed automatically: numbers and true/false pass through as SQL literals, empty cells become NULL, and everything else is single-quoted with embedded quotes safely escaped. Quoted CSV fields with commas are handled too. It all runs in your browser.

Built and maintained by Meet Shah · Last updated 2 August 2026

What this tool is used for

Loading a spreadsheet extract into a database without writing an import script.
Producing seed data for a test database from a real export.
Generating INSERT statements to review before running them against a schema.
Turning a one-off data fix supplied as CSV into runnable SQL.
Migrating a small reference table between systems.

Frequently Asked Questions

How are values escaped?: Single quotes are doubled per the SQL standard, so O'Brien becomes 'O''Brien'. This is the minimum — string-building SQL is inherently injection-prone, which is why parameterised inserts are safer for anything automated.
How are column types inferred?: By scanning values, which is a heuristic and can be wrong. A zip code column of 01234 looks numeric and loses its leading zero; a column that is entirely digits until row 900 gets typed as integer and then fails. Review the DDL before running it.
How are empty fields handled?: This is a genuine ambiguity: CSV cannot distinguish an empty string from NULL. Most converters treat an empty field as NULL, but ,, and ,"", mean the same thing in CSV and different things in SQL.
Should I use one INSERT or many?: Multi-row INSERTs are far faster — often 10x — because each statement has fixed overhead. For very large files, the database's own bulk loader (COPY, LOAD DATA INFILE) beats generated SQL by a wide margin.
Does SQL dialect matter?: Yes. Identifier quoting differs (backticks in MySQL, double quotes in Postgres, brackets in SQL Server), as do types — Postgres has no UNSIGNED, and MySQL's DATETIME differs from TIMESTAMP WITH TIME ZONE.
Why is a generated INSERT statement risky with untrusted data?: Because escaping by string substitution is exactly the pattern SQL injection exploits. Generated statements are fine for a one-off import you inspect; anything repeatable should use parameterised queries or the database's own bulk loader.
What is the faster route for a large file?: The database's native loader — `COPY` in PostgreSQL, `LOAD DATA INFILE` in MySQL. They bypass statement parsing entirely and are usually an order of magnitude faster than a file of INSERTs.

Common errors and gotchas

Not escaping single quotes in values, which breaks the statement and is the classic injection route.
Assuming every column is text, so numbers and dates arrive quoted and the database coerces or rejects them.
Losing empty-versus-null distinction, where an empty CSV field could mean either.
Generating one enormous statement that exceeds the server's limit rather than batching.
Trusting the column order to match the table, when a header rename silently shifts everything.