CSV to SQL Converter

Get a runnable SQL script out of a CSV

Loading a CSV into a database by hand is a slog. You stare at a few thousand rows and start typing INSERT statements one at a time, or you wrestle with an import wizard and its opinions about quoting and delimiters. This converter skips that. Point it at a CSV and it hands back a plain .sql file: a CREATE TABLE at the top, then an INSERT statement for every row underneath.

It's aimed at the quick, unglamorous jobs. Seeding a local dev database, dropping a spreadsheet export into a table, getting sample data into a schema so you can start writing queries. The output is text, so you can open it, read it, and change it before you run a single line.

What the script actually contains

The output has a fixed shape, and knowing it up front saves confusion. Two comment lines sit at the top, noting that it's a CSV export and the timestamp it was generated. Then the CREATE TABLE: the table is always named csv_export, it gets an auto-incrementing id column set as the primary key, and each header from your CSV becomes its own column. Below that comes one INSERT INTO csv_export (...) VALUES (...); line for each data row, in the order they appeared.

Column names are taken from your header row, lowercased, with anything that isn't a letter, number, or underscore replaced by an underscore. So a header like First Name turns into first_name, and Order # turns into order__. If two of your headers reduce to the same name, you'll end up with duplicate columns in the CREATE TABLE, so it's worth a quick look at the header line before you convert.

How your data gets handled

Your file is read and parsed in the browser. It works out the delimiter on its own from the header line, so comma, semicolon, tab, and pipe files all load without you setting anything. Quoted fields and doubled quotes inside them are parsed the standard CSV way.

On the SQL side, every value is wrapped in single quotes, and any single quote inside a value is doubled, so a name like O'Brien becomes 'O''Brien' and won't break the statement. That same rule is why numbers and dates come out quoted as strings, '30' and '2026-07-20', since every column is TEXT. Empty cells become an empty string, not NULL. One thing to watch: single quotes are escaped but backslashes are not, so if your data holds backslashes and you're on MySQL's default settings, eyeball those values before running. UTF-8 is kept intact and the table is declared utf8mb4, so accented characters and non-Latin scripts survive the trip. If your data starts life as JSON rather than a spreadsheet, you'll want a CSV in hand before you come here.

The JSON to CSV converter handles that first hop, and its output drops straight into this tool.

Where it stops short

This is a deliberately plain generator, and a handful of its choices are locked in. Being upfront about them saves a surprise later.

• The table is always called csv_export. Need a different name? Rename it in the script, or run an ALTER TABLE after importing.
• There's no type detection. Every column comes out TEXT, even ones that are obviously integers or dates. If you want typed columns, edit the CREATE TABLE before you run it.
• The syntax is MySQL and MariaDB flavored: backtick-quoted names, int(11), ENGINE=InnoDB, utf8mb4. Those two run it as-is. Postgres, SQL Server, SQLite, and Oracle need edits first.
• Rows are written as separate INSERT statements, not batched multi-row inserts, and it's all one file. For a few thousand rows that's fine; for a very large export it makes a long script.

My honest take: treat the result as a strong first draft, not a finished migration. For a throwaway dev table it's ready to run. For anything headed to production, open it and set real column types and a real table name first. Those five minutes beat reloading a table full of TEXT columns down the line.

A real example

Say you pulled 4,000 customer records out of an old CRM as customers.csv, with columns like Full Name, Email, Signup Date, and Plan. Drop it in, pick SQL, and you get back a file named customers-thefreeconverter.com.sql. Inside is a CREATE TABLE csv_export with full_name, email, signup_date, and plan as TEXT columns plus the id key, followed by 4,000 INSERT lines. Rename the table to customers, switch signup_date to a DATE, and run it against your local MySQL. It takes longer to describe than to do.

Running the script

Once you've got the .sql file, feed it to your database however you normally would, whether that's piping it into the mysql client or pasting it into a GUI tool. The id column fills itself in as rows insert, so you leave it alone. One gotcha: the CREATE TABLE has no IF NOT EXISTS, so running the same script twice throws a "table already exists" error. Drop the table first, or delete the CREATE TABLE block if you only want the INSERTs the second time around.

Cleaning the data before you convert

Because the CSV opens in an editable grid, you can tidy it before any SQL exists. Sort by a column, filter down to the rows you actually want, rename a header so its column name comes out cleaner, or drop duplicate rows. Fixing it here means the INSERTs match what you want in the table, instead of importing clutter and deleting it afterward.

When a different tool fits better

If a spreadsheet is where this data really needs to live, send it to Excel and skip the database step entirely.

And if you're loading an app or an API rather than a database, convert it to JSON instead to hand it clean, structured records instead of raw INSERT statements.

On privacy: the CSV itself is never uploaded, since it's parsed in your browser. Building the SQL does send the parsed rows to the server, where the .sql file is generated and held just long enough for you to download it. Those generated files are cleared automatically within about ten minutes, and nothing is kept or shared after that.