ToolLineup

CSV to SQL Converter

This CSV to SQL converter turns a spreadsheet export into INSERT statements, taking the column names from your header row. Values are escaped for SQL — an apostrophe is doubled — so a name like O’Brien cannot break the statement or be used to inject another one. Type detection keeps numbers and booleans unquoted while leaving values with leading zeros as strings, so postcodes and account IDs survive intact, and empty cells become NULL rather than an empty string. You can name the target table, choose the identifier quoting style for MySQL, PostgreSQL or SQL Server, emit one multi-row INSERT instead of a statement per row, and prepend a CREATE TABLE with column types inferred from your data.

How it works

Turns each row into an INSERT statement, taking the column names from your header row. Values are quoted and escaped for SQL — an apostrophe is doubled, so a name like O'Brien cannot break the statement or be used to inject one.

Type detection keeps numbers and booleans unquoted while leaving values with leading zeros as strings, so postcodes and account IDs survive. Empty cells become NULL.

The conversion runs entirely in your browser — nothing you paste or upload is sent to a server.

CSV input
Paste CSV or upload a .csv file…
SQL output

How to convert CSV to SQL

  1. Paste your CSV into the input on the left, or upload a .csv file.
  2. Set the table name and pick the identifier quoting your database uses.
  3. Copy the statements, or download them as a .sql file.

Escaping, and why it matters

Building SQL by concatenating strings is how injection bugs happen. A value containing an apostrophe — O'Brien, or something deliberately hostile — would otherwise close the string literal early and let the rest of the value be read as SQL.

Every value here has its apostrophes doubled, which is the standard SQL escape, and MySQL backslash escaping is applied as well when you select backtick quoting. A value cannot terminate the statement it sits in.

Type detection

Numbers and booleans are written unquoted so the database stores them as numbers and booleans. Values with a leading zero are deliberately left as strings — turning 01234 into 1234 would quietly corrupt postcodes, phone numbers and account references. Empty cells become NULL, since a blank cell in a spreadsheet almost always means "no value" rather than "empty string".

One statement per row, or one big INSERT

A statement per row is easier to read, easier to diff and easier to re-run selectively when one fails. A single multi-row INSERT is dramatically faster for a large import, because the database plans the statement once instead of thousands of times. Pick based on whether you are debugging or loading.

The CREATE TABLE is a starting point

Column types are inferred from the values actually present: whole numbers give INTEGER, decimals give DECIMAL, and text gives a VARCHAR sized to fit the longest value in that column. That is a reasonable first draft, not a schema. Review it before running it — the real schema needs primary keys, indexes, constraints and a considered opinion about how much the longest value might grow.

Common use cases

  • Loading a spreadsheet a colleague sent you into a development database.
  • Building seed data for a new table from a reference list.
  • Turning an export from one system into an import for another.

Frequently asked questions

How do I convert CSV to SQL?

Paste your CSV into the left panel or upload a .csv file. The INSERT statements appear on the right, ready to copy or download as a .sql file.

Are values escaped safely?

Yes. Apostrophes are doubled, which is the standard SQL escape, and MySQL backslash escaping is applied when you choose backtick quoting. A value cannot terminate the statement it sits in.

Can it generate the CREATE TABLE too?

Yes. Tick include CREATE TABLE and column types are inferred from the values actually present — integer, decimal, boolean or a VARCHAR sized to fit the longest value in that column.

What happens to empty cells?

They become NULL. An empty string and a missing value are different things in a database, and NULL is almost always what a blank cell in a spreadsheet means.

One statement per row or one big INSERT?

Both. A statement per row is easier to read and to re-run selectively; a single multi-row INSERT is considerably faster to execute for large imports.

Should I review the SQL before running it?

Yes, always. The output is a starting point built from your data — check the table name, column types and any constraints your schema needs before running it against a real database.

Related tools