Paste a CSV, get runnable SQL
Type inference, quoted identifiers, escaped literals, batched values and a pre-flight report that catches the things that abort a load halfway through.
Identifier and upsert options
Why not just ask an AI model for the INSERT statements
Because the failure is silent. A model writing fifty INSERT statements will count columns from memory, forget to escape the apostrophe in O'Brien, write the word NULL for a cell that was actually an empty string, and never notice that two rows share the same primary key. That last one is the expensive mistake: inside a transaction the whole load rolls back, and on PostgreSQL the log points at one row out of fifty thousand.
This tool does the mechanical part exactly, and refuses to stay quiet about the rest. It counts columns, escapes every dialect correctly, wraps the load in a transaction so a failure is all-or-nothing, and reports the problems that would otherwise show up as a failed job: ragged rows, mixed types in one column, duplicate primary keys, and numbers that Excel destroyed before you ever opened the file.
The Excel problem this tool is built around
Open a CSV in Excel, save it, and every identifier longer than fifteen digits is rewritten as a float. 0044123456789 becomes 12345. 13800138000 becomes 1.38001E+10. Nothing in the SQL is wrong; the data was already gone before the file reached you.
So the tool looks for those cells. If it finds them you get the count, the column, and the honest answer: the digits Excel dropped cannot be recovered from the file, so this is a warning about your export pipeline, not something a converter can repair. The repair switch rewrites what survived (1.38001E+10 to 13800100000, with the last digits rounded by Excel) and switches the column to a text type so the next export is clean. For a real fix on the way out, quote the column in Excel before you export, or save as .xlsx instead of .csv.
Every non-empty cell in a column decides the type: integers become INTEGER or BIGINT, decimals keep their scale as NUMERIC(p,s), ISO dates and timestamps are recognised, and one word among numbers widens the column to text instead of silently truncating.
Single quotes are doubled for PostgreSQL, SQLite, SQL Server and Oracle. MySQL additionally escapes backslashes. Non-ASCII strings get the N'...' prefix on SQL Server, where a plain literal would lose Unicode.
Rows per INSERT is a control, not a guess. MySQL, SQL Server and Oracle cap a statement around 1,000 bind parameters, so a wide table needs smaller batches than a narrow one. Default is 100 rows.
user, order, key and group break a CREATE TABLE in some dialect. Quoting uses the character that dialect expects: double quotes, backticks or square brackets.
Quoted fields containing commas, newlines and doubled quotes parse the way the standard says, so a description field with a line break in it does not become four broken rows.
The script ends with COUNT(*), a per-column NULL count and a per-column distinct count, so a load can be checked instead of assumed.
How to use it
- Paste the CSV, drop a file on the input, or press Load sample to see the shape of the output.
- Set the table name and the dialect. If the first row is not a header, switch that off and the column names become
column1,column2, and so on. - Press Generate SQL. Read the data quality report. Anything red will abort a transaction.
- Copy or download the script and run it. If you are loading into a table that already exists, turn off Include CREATE TABLE and pick an upsert style.
How do I convert a CSV file into INSERT statements?
Paste the CSV into the input box, or drop a .csv, .tsv, .json or .xlsx file on it. Set the table name, pick your database dialect, then press Generate SQL. You get a CREATE TABLE statement, batched multi-row INSERT statements wrapped in a transaction, and verification queries. The whole file stays in your browser.
Why did my CSV turn numbers into scientific notation like 1.23457E+11?
That is Excel mangling the export, not the SQL. Excel stores numbers as double precision, so a phone number or an 18-digit account id gets rounded and written in scientific notation. The original digits are gone from the file. This tool detects those cells, reports how many are affected and can rewrite them to the digits that survived, but it also tells you to store that column as TEXT so the next export keeps every digit.
Can an AI chatbot write the INSERT statements for my CSV?
For three rows, sometimes. For a real export it fails quietly: it miscounts columns, drops a value after a comma, forgets that an apostrophe in O'Brien breaks the string literal, treats an empty cell as the word NULL, and never notices that two rows share the same primary key. A deterministic converter counts the columns for you, escapes the quotes, and fails loudly on the duplicate key that would abort the whole transaction.
How large a CSV can this handle?
Conversion runs in your browser with no upload limit from our side. Type inference reads the first 20,000 rows, which is plenty to pick a column type, and the generated SQL holds every row. Very large files (hundreds of thousands of rows) can make the browser tab slow or run out of memory, and most databases reject single statements with more than about 1,000 bind parameters, so use the batch size control.
What is the difference between ON CONFLICT, ON DUPLICATE KEY UPDATE and MERGE?
They are the same idea written three ways. PostgreSQL and SQLite use INSERT ... ON CONFLICT (key) DO UPDATE. MySQL uses ON DUPLICATE KEY UPDATE. SQL Server and Oracle use MERGE INTO ... USING. Pick the one your database understands, or leave it on plain INSERT for a first load. MERGE is the least portable and the one with the most engine-specific bugs, so on SQL Server a two-step UPDATE then INSERT is often safer for repeated runs.
Why are my identifiers quoted in the output?
Because words like user, order, group, key or select are reserved keywords in at least one of the five supported dialects. Unquoted, CREATE TABLE fails or the column silently becomes a syntax error. This tool quotes only identifiers that need it, using the right character per dialect: double quotes for PostgreSQL and SQLite, backticks for MySQL, square brackets for SQL Server, and plain uppercase names for Oracle. You can force quoting on or off in the options.
Is my CSV uploaded anywhere?
No. Parsing, type inference, diagnostics and SQL generation all run in the page. There is no server-side converter, no analytics call on your data and no account. The only external script is the Apache SheetJS reader, and it is downloaded only if you pick an .xlsx file, and it reads the file locally too.
How do I verify the import actually worked?
The generated script ends with verification queries: a total row count, a per-column NULL count, and a per-column distinct count. Run them after the import and compare the numbers with the report this tool produced from your file. If COUNT(*) is lower than the row count in the report, the transaction aborted part way, and on PostgreSQL the log will name the exact row that failed.
Comments & Ratings