CSV to SQL Converter: CREATE TABLE & INSERT Statements

What you get

Paste a CSV or open a file and the tool writes two things: a CREATE TABLE statement with a column type guessed for every column, and INSERT statements that load every row. Pick your database and the types, quoting and escaping change to match. Copy it into psql, the MySQL client, SQLite, SSMS or any GUI and run it.

It is the fastest way to get a spreadsheet into a database when you do not want to fight an import wizard, need a seed file for tests, or want to hand someone a script they can run anywhere.

How types are inferred

Every non-empty value in a column is checked, not just the first few rows. The tool picks the narrowest type that fits all of them. Whole numbers become INTEGER, or BIGINT once any value passes 2,147,483,647. Numbers with decimals become NUMERIC or DECIMAL with precision and scale sized to your data, so 120.50 and 87.25 give DECIMAL(5,2). Columns of only true and false become BOOLEAN (BIT on SQL Server, 0 and 1 on SQLite). YYYY-MM-DD values become DATE, and ISO timestamps become TIMESTAMP, DATETIME or DATETIME2 depending on the dialect. Anything else is text: VARCHAR sized to the longest value in MySQL, NVARCHAR in SQL Server, TEXT in PostgreSQL and SQLite.

The detected type for each column shows as a chip above the output. If one is wrong, fix that line of the CREATE TABLE by hand; the INSERT values will still load, because the database casts them.

The leading-zero rule

ZIP codes, phone numbers, SKUs and employee IDs often start with zero. Treat 02134 as a number and it becomes 2134, and a Boston ZIP code is gone. So any value with a leading zero, other than 0 itself or 0.5 style decimals, forces the column to text. The sample on this page has a zip column for exactly this reason. Excel users know the pain: open a CSV of ZIP codes in Excel, save it, and the zeros are already gone before you get here. Check the raw file.

Escaping, the part you must not get wrong

A name like O'Brien breaks naive generators, because the apostrophe ends the SQL string early. At best the script fails. At worst, with hostile data, it is SQL injection. Every string here is wrapped in single quotes with internal quotes doubled, the SQL standard: 'Ada O''Brien'. MySQL also treats backslash as an escape character by default, so backslashes are doubled for MySQL output. SQL Server strings get the N prefix, N'...', so accented names and emoji survive in NVARCHAR columns.

Identifiers are quoted too, in each dialect's style: "double quotes" for PostgreSQL and SQLite, `backticks` for MySQL, [brackets] for SQL Server. That means column headers with spaces, capitals or reserved words like order or date work without renaming. In PostgreSQL, quoted names are case-sensitive, so "Email" and email are different columns. Lowercase your headers first if you want to query without quotes.

The CSV parser follows RFC 4180: fields in double quotes can contain commas, line breaks and doubled quotes. Lin, Mei in quotes stays one value. Delimiters are auto-detected from comma, semicolon, tab and pipe, which covers European Excel exports that use semicolons.

Batching and big files

One INSERT per row is slow to run and huge to read. By default rows are grouped 100 per statement, which is dramatically faster. SQL Server caps a single VALUES list at 1000 rows, so batches are capped there automatically. Wrap in transaction adds BEGIN and COMMIT, so a failed row rolls back the whole load instead of leaving a half-imported table.

For really large files, hundreds of thousands of rows, generated INSERTs are the wrong tool. Use the native bulk loader: COPY in PostgreSQL, LOAD DATA INFILE in MySQL, .import in the sqlite3 shell, BULK INSERT or bcp in SQL Server. They are orders of magnitude faster. Use this tool to get the CREATE TABLE right, then bulk-load into it.

Pitfalls

Empty cells. By default an empty cell becomes NULL. Untick Empty cells as NULL to get empty strings instead, and remember that in most databases NULL and '' behave differently in WHERE clauses and unique constraints.

Time zones. PostgreSQL and SQLite take ISO timestamps with their offset as-is. MySQL DATETIME and SQL Server DATETIME2 do not store offsets, so the offset is dropped from the value. Convert to UTC before exporting if the zone matters, or change the column to TIMESTAMPTZ or DATETIMEOFFSET.

No primary key or indexes are added, because the tool cannot know your intent. Add PRIMARY KEY to the id column and any indexes before loading production data.

Your CSV never leaves the browser. Customer lists and exports stay on your machine.