Skip to main content

CSV to SQL Converter

Convert CSV files to CREATE TABLE and INSERT statements

Turn a CSV file into runnable SQL: a CREATE TABLE statement with types inferred from your data, followed by INSERT statements you can paste straight into a client. Choose MySQL, PostgreSQL, SQLite, or SQL Server and the output is written for that dialect rather than one generic flavour.

The parts that usually break generated SQL are handled properly. Identifiers are quoted the way each dialect expects — backticks for MySQL, double quotes for PostgreSQL and SQLite, brackets for SQL Server — so a column called order or a table name with a space still runs. String literals escape single quotes everywhere and backslashes on MySQL, which treats them as escape characters by default.

Inferred types are sized to the values that produced them. An integer column that exceeds 32-bit range becomes BIGINT, an identifier too long for BIGINT stays text rather than being silently truncated, and a decimal column gets a precision and scale that actually fit instead of a fixed DECIMAL(10,2).

Files stay on this deviceRuns entirely in your browserFree — no signup

Drop your file here or browse from your device

Accepts CSV, TSV, TXT. Maximum input: 10 MiB. Files above this hard limit are rejected before local processing.

How to Convert

  1. Upload your CSV file or paste CSV data
  2. Set the table name and choose your SQL dialect
  3. Decide whether to include CREATE TABLE, batch the INSERTs, and treat empty cells as NULL
  4. Review the generated SQL, then copy it or download the .sql file

Features

  • Four dialects with dialect-correct types: MySQL, PostgreSQL, SQLite, SQL Server
  • CREATE TABLE with column types inferred from your data (optional)
  • Identifiers quoted per dialect so reserved words and spaces still run
  • Integer widening to BIGINT, and text for identifiers too long to store as a number
  • DECIMAL precision and scale sized to the observed values
  • Batched multi-row INSERT statements with a configurable batch size
  • Choose whether an empty cell becomes NULL or an empty string
  • Editable table name, copy or download the .sql file

Use Cases

  • Load a spreadsheet export into MySQL, PostgreSQL, SQLite, or SQL Server
  • Generate seed or fixture data for a development database
  • Migrate reference tables maintained in a spreadsheet into a real schema
  • Produce a repeatable import script instead of a one-off GUI import
  • Draft a starting schema from sample data before refining the types by hand
  • Move data into a database that has no CSV import path available

Frequently Asked Questions

Which SQL dialects are supported?

MySQL and MariaDB, PostgreSQL, SQLite, and SQL Server. The dialect changes the identifier quoting, the generated column types, the string escaping, and how the CREATE TABLE existence check is written.

Does it generate CREATE TABLE as well as INSERT?

Yes, and it is optional. Turn it off when the table already exists and you only want the INSERT statements.

How are column types decided?

Each column is scanned and given the narrowest type that still holds every value: INT, then BIGINT for wider integers, DECIMAL sized to the digits actually present, DATE or TIMESTAMP for ISO values, a boolean type for true/false, and otherwise a VARCHAR sized to the longest value or TEXT beyond 255 characters. Treat it as a solid starting point and adjust constraints to suit your schema.

What happens to a long numeric ID?

It stays a text column. An integer too wide for BIGINT would lose digits if stored as a number, so account numbers, order references, and similar identifiers keep their exact value instead.

Will a column named order or select break the SQL?

No. Every identifier is quoted for the target dialect, so reserved words, spaces, and punctuation in header names all survive. Blank headers are named by position and duplicates get a numeric suffix so the DDL stays valid.

How are quotes and backslashes in my data escaped?

Single quotes are doubled in every dialect, which is the SQL standard. On MySQL backslashes are also escaped, because MySQL treats a backslash inside a string as an escape character by default while the other dialects do not.

What do empty cells become?

NULL by default, which suits most imports. Switch the option off when an empty string is meaningful in your data or the target column is NOT NULL.

Why are the INSERT statements batched?

One multi-row INSERT per batch executes far faster than thousands of single-row statements. The batch size is configurable, and you can turn batching off entirely if you need one statement per row.

Is my CSV uploaded anywhere?

No. The file is parsed and the SQL generated in your browser, so the data never reaches the app server.

Need to convert the other way? Try our Sql To Csv