CSV to SQL Converter

Q: Is the escaping here safe against SQL injection?

The escaping is correct for producing valid SQL literals — single quotes are doubled, which is the standard rule. But that is not the same as being safe against injection, and the distinction matters. These statements are for loading data you already have and trust, run once by you against your own database. Never build queries this way from user input at runtime: use bound parameters, which separate the query from the data entirely rather than relying on escaping being right every time.

Q: How are column types inferred?

Conservatively, from the values actually present. A column is INTEGER only if every non-empty value is a whole number, DECIMAL if they are all numeric, BOOLEAN if they are all true or false, and DATE if they all match a plain YYYY-MM-DD pattern. Anything mixed falls back to VARCHAR sized to the longest value, or TEXT if that exceeds 255. The bias is deliberate: guessing INTEGER for a column that turns out to contain one piece of text fails the whole import, so ambiguity resolves to the safer type.

Q: Why are my leading-zero codes not becoming numbers?

Because they are codes, not numbers, and converting them destroys them. A postcode of 01234 or a product code of 007 would lose its leading zero and become a different value that can never be recovered. The parser deliberately keeps any value with a leading zero as text, which means the inferred column type will be VARCHAR rather than INTEGER — which is almost certainly what you want for an identifier that happens to be made of digits.

Q: What is the batch size for?

It controls how many rows go into each INSERT statement. One row per statement is the most readable and the easiest to debug when a single row fails. Batching many rows into one statement is dramatically faster for large imports, because the database does the work once rather than per row. A few hundred rows per statement is a reasonable middle ground; very large batches can exceed a server's maximum packet size, which is its own kind of failure.

Q: Does it handle MySQL and PostgreSQL differently?

Only in how identifiers are quoted, which is the main portable difference. MySQL uses backticks around table and column names; the standard, which PostgreSQL and SQLite follow, uses double quotes. Everything else the tool emits is standard SQL. The generated CREATE TABLE is a starting point rather than a finished schema — it has no primary key, no indexes and no constraints, all of which you should add deliberately rather than inherit from a guess.

Q: What happens to empty cells?

They become NULL rather than an empty string, which is usually right but worth knowing about. The two are genuinely different in SQL: NULL means unknown and does not equal anything, including itself, while an empty string is a known value that happens to be empty. If your data uses empty cells to mean a real empty value rather than missing data, the distinction will matter to your queries later, and you may want to substitute an empty string explicitly.

Turn CSV into INSERT statements with values escaped, column types inferred and an optional CREATE TABLE.

CSV

Table name

Identifier quoting

Rows per statement

Include a CREATE TABLE with inferred types

SQL

Everything is generated in your browser. The escaping produces valid SQL literals, but this is for loading data you trust — never build runtime queries this way, use bound parameters.

What It Does

Paste a CSV and get SQL you can run to load it. The statements come with values escaped properly — single quotes doubled, numbers left unquoted, empty cells turned into NULL rather than empty strings — and optionally a CREATE TABLE derived from the data. The type inference is deliberately cautious. A column becomes INTEGER only when every value in it is genuinely a whole number, and anything ambiguous falls back to text, because guessing a narrow type that one row violates fails the entire import. Values with leading zeros stay text for the same reason: a postcode of 01234 turned into a number is destroyed rather than converted. Batch size is adjustable, since one row per statement is easiest to debug while batching is far faster for a large load.

When to Use It

A spreadsheet of reference data needs loading into a new table and you would rather not configure an import wizard.
You need seed data for a development database and have the values in a CSV already.
A client sent a data export and you want to see what schema it implies before designing the real one.
You are moving a lookup table between systems and need portable SQL rather than a database-specific dump.
A migration needs a one-off data load and you want the statements in version control rather than run by hand.

Worked Examples

id,name,price,active
1,Widget,9.99,true
2,Gadget,19.50,false

Clean inference: id becomes INTEGER, price DECIMAL, active BOOLEAN and name a VARCHAR. Numbers and booleans are emitted unquoted, which is what makes the types actually apply.

code,postcode,qty
A1,01234,5
B2,00987,12

The leading-zero case. Both code columns stay text and the inferred type is VARCHAR, because turning 01234 into a number would silently destroy the value.

name,note
Jane,"O'Brien said ""hello"""
Sam,

Escaping under pressure. The apostrophe is doubled so the literal is valid, the embedded quotes survive the CSV parsing, and Sam's empty note becomes NULL rather than an empty string.

Features

INSERT statements with correct SQL escaping

Optional CREATE TABLE with inferred column types

Conservative type inference that avoids failed imports

Leading-zero codes preserved as text

Empty cells emitted as NULL

Adjustable batch size per statement

MySQL backtick or standard double-quote identifiers

Custom table name

Automatic delimiter detection and RFC 4180 parsing

Runs entirely in your browser

How to Use

1. Paste your CSV or import a file. 2. Set the table name. 3. Choose your dialect so identifiers are quoted correctly. 4. Turn on CREATE TABLE if you need the schema as well as the data. 5. Adjust the batch size — one row per statement for debugging, more for speed — then copy the SQL.

Common Mistakes

Treating generated SQL as safe for user input. The escaping is correct for building a literal, but runtime queries need bound parameters — escaping is not a substitute for parameterisation.
Letting an identifier be inferred as a number. Postcodes, phone numbers and product codes with leading zeros are text, and converting them loses information permanently.
Running the generated CREATE TABLE as a finished schema. It has no primary key, no indexes and no constraints — it is a starting point to edit, not a design.
Batching too aggressively. Very large multi-row inserts can exceed the server's maximum packet size, and a failure at that point tells you very little about which row was at fault.
Not noticing that empty cells become NULL. NULL and an empty string behave differently in comparisons, and the difference surfaces much later than the import.

Frequently Asked Questions

Is the escaping here safe against SQL injection?

How are column types inferred?

Why are my leading-zero codes not becoming numbers?

What is the batch size for?

Does it handle MySQL and PostgreSQL differently?

What happens to empty cells?