Is the generated SQL safe to run?

Values are escaped by doubling single quotes, which prevents a value from breaking out of its literal. Still review the output before running it, and never build runtime queries by concatenating user input, use parameterised queries for that.

Why did my empty cells become NULL?

Because a blank cell usually means "no value". If your schema needs an empty string instead, turn off type inference so all values are quoted as text.

Can I load a very large CSV this way?

For more than a few thousand rows, use your database's bulk loader (COPY, LOAD DATA INFILE or bcp), which is far faster than individual INSERT statements.

Generators

CSV to SQL INSERT

Generate INSERT statements from CSV rows.

LiveCtrl+↵

Inputcsv0 lines · 0 chars

Outputsql0 lines · 0 chars

Options

Table name

SQL dialect

Input delimiter

Detected automatically unless you pick one.

Convert numbers and booleans to real types

Values with leading zeros stay strings so IDs are preserved.

Single multi-row INSERT

One statement with all rows, instead of one statement per row.

About this tool

This turns a CSV export into INSERT statements you can run directly, the fastest route for seeding a development database, loading reference data, or moving a spreadsheet into a table.

Because generated SQL gets executed, escaping is the thing that matters most here. Single quotes in values are doubled per the SQL standard, so a name like O'Brien cannot terminate its string literal early. Review generated SQL before running it, and use parameterised queries for anything driven by untrusted input at runtime.

How to use it

Paste or upload your csvDrop a file onto the input pane, use the file picker, or paste the text directly.
Adjust the options if neededThe defaults suit most input; open Options to change the behaviour.
Generate SQLPress Generate SQL, or use Ctrl+Enter (Cmd+Enter on macOS).
Copy or downloadCopy the result, or download it as a .sql file.

Worked examples

Each example below is executed against this tool by the test suite, so what you see is what the tool actually produces.

Rows with a quote and a blank cell

Input

id,name,email
1,Alice,alice@example.com
2,O'Brien,

Output

INSERT INTO "users" ("id", "name", "email") VALUES (1, 'Alice', 'alice@example.com');
INSERT INTO "users" ("id", "name", "email") VALUES (2, 'O''Brien', NULL);

The apostrophe is doubled so it cannot break the literal; the empty cell becomes NULL.

What to watch for

The details that decide whether a conversion is correct, and where information can be lost without any error being raised.

Column names come from the header row: The first CSV row supplies the column list, and each subsequent row becomes one set of values. The header names must match your table's columns, rename them in the CSV first if they do not, since the generator has no schema to check against.
How values are escaped: Single quotes are doubled, which is the SQL standard escape: O'Brien becomes 'O''Brien'. That keeps the value inside one string literal no matter what it contains. Backslashes are not treated as escapes, since standard SQL does not use them, note that MySQL does by default unless NO_BACKSLASH_ESCAPES is set.
Type inference and NULL: Values that are unambiguously numbers are written unquoted, true and false become boolean literals, and an empty cell becomes NULL rather than an empty string. That last choice is worth knowing: if a blank should mean the empty string in your schema, turn type inference off so every value is quoted as text.
Identifier quoting differs by dialect: PostgreSQL and standard SQL use double quotes, MySQL and MariaDB use backticks, and SQL Server uses square brackets. Selecting the right dialect produces the correct form, which matters for any identifier that is a reserved word or contains unusual characters.
One statement per row, or one for all: Separate statements are easier to debug, since a failure names the row that caused it, and they work with any database. A single multi-row INSERT is considerably faster for bulk loads but has practical limits, Oracle does not support the syntax at all, and MySQL caps it by max_allowed_packet. Split very large batches.
Where a real bulk loader is better: For tens of thousands of rows, your database's native loader (PostgreSQL COPY, MySQL LOAD DATA INFILE, SQL Server bcp) will be dramatically faster than generated INSERTs. This tool is aimed at the hundreds-of-rows case.

Limitations

Has no access to your schema, so column names and types are not validated.
Empty cells become NULL unless type inference is disabled.
Not suited to very large loads; use a native bulk loader instead.
Processing happens in your browser, so very large inputs are bounded by available memory. Files above roughly 10 MB are handled but will feel slower, and multi-hundred-megabyte files are better suited to a command-line tool.

Questions

Is the generated SQL safe to run?: Values are escaped by doubling single quotes, which prevents a value from breaking out of its literal. Still review the output before running it, and never build runtime queries by concatenating user input, use parameterised queries for that.
Why did my empty cells become NULL?: Because a blank cell usually means "no value". If your schema needs an empty string instead, turn off type inference so all values are quoted as text.
Can I load a very large CSV this way?: For more than a few thousand rows, use your database's bulk loader (COPY, LOAD DATA INFILE or bcp), which is far faster than individual INSERT statements.