- Home
- CSV Converters
- CSV to SQL Converter
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).
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
- Upload your CSV file or paste CSV data
- Set the table name and choose your SQL dialect
- Decide whether to include CREATE TABLE, batch the INSERTs, and treat empty cells as NULL
- 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.
Related Tools
SQL to CSV Converter
Extract data from SQL INSERT statements to CSV
CSV Query
Query a CSV with SELECT, WHERE, GROUP BY, ORDER BY, and LIMIT
Parquet to CSV Converter
Convert Apache Parquet files to CSV format in your browser
CSV Viewer
View CSV files in a spreadsheet-style grid with sorting, filtering, and search