Loading a spreadsheet into a database is one of those jobs that looks trivial until the data has an apostrophe in it. Hand written SQL breaks on names like O'Brien, on values containing the delimiter, and on numbers that were silently stored as text. Generating the statements mechanically removes that entire class of mistake.
The work is done locally by JavaScript in the page. Nothing is uploaded, so a table of user records or invoice lines stays on your machine, which matters because the data you are most likely to load into a database is also the data you are least able to share.
When to convert CSV to SQL rather than use an import command
Every database ships a bulk loader. MySQL has LOAD DATA INFILE, Postgres has COPY, and SQLite has the .import dot command. When you have shell access to the server and a file sitting on it, those are faster and should be your first choice. Generated statements are for the situations where that path is closed.
That path is closed more often than you would expect. Managed services frequently disable file level loading, migration frameworks want a plain .sql file they can version and replay, and reviewers want to read a change before it runs. In each case a text file full of inserts is the artefact everyone can work with.
- Your hosting provider blocks LOAD DATA INFILE or server side COPY.
- The statements need to live in a migration file under version control.
- Somebody has to review the exact rows before they are applied.
- You are seeding a test database and want the data checked in.
- Use the native bulk loader instead when the file is very large and you control the server.
Escaping, quoting and the apostrophe problem
A string literal in SQL is wrapped in single quotes, and a literal single quote inside it is written by doubling it. That one rule is where most hand written imports fail, because a single unescaped apostrophe turns the rest of the row into syntax the parser cannot make sense of.
Every value this CSV to SQL converter produces is escaped by doubling internal single quotes, and backslashes are escaped as well when you select MySQL, which treats a backslash as an escape character by default where the standard dialects do not. Identifiers are quoted using the convention of the dialect you pick, so backticks for MySQL and double quotes for Postgres and SQLite.
Escaping is a correctness measure, not a security measure. Do not build application queries by concatenating values, use parameter binding for that.
Types, NULLs and what the tool refuses to guess
CSV has no type system. Every cell is text, and the meaning of 1000, 1,000 and 1e3 depends on who wrote the file. One conservative rule applies: a value that looks like a plain integer or decimal is written unquoted, everything else becomes a quoted string. Turn that off to quote everything.
Empty cells are ambiguous in the same way. An empty field can mean the empty string or an absent value, and only you know which. The NULL toggle chooses between writing an empty quoted string and writing the NULL keyword, so the decision is explicit rather than silently made for you.
The optional CREATE TABLE statement uses TEXT for every column deliberately. Guessing a column width or a numeric precision from a sample of rows produces schemas that fail on the first row that does not match. Treat the generated table as a scaffold to edit, not as a finished schema.
How this CSV to SQL converter builds each statement
The CSV is parsed with a state machine that follows RFC 4180, so quoted fields containing commas, line breaks or doubled quotes are read correctly rather than split apart. The header row supplies the column list, and each remaining row supplies one tuple of values.
In single statement mode you get one INSERT per row, which is easy to diff and easy to run partially if something fails half way. In batch mode the rows are grouped into multi row inserts of a size you choose, which is dramatically faster on large loads because the database parses and commits far fewer statements.
A malformed quote stops the run and reports the line and column where the quote opened, so you can fix the exact cell.
Running the generated SQL safely
Read the output before you run it. This is a csv to insert statements generator, not a migration system, and it has no idea what constraints, triggers or foreign keys exist on the target table. Running a few thousand inserts against a table with a unique index will stop at the first conflict unless you have planned for it.
Wrap the statements in a transaction when your dialect supports it, so a failure part way through rolls back rather than leaving a half loaded table. On very large files, run a batch of a hundred rows first and confirm the shape is right before committing to the rest. Used that way a simple sql insert generator saves hours without introducing risk.
How to convert CSV to SQL
- 1
Paste or drop your CSV
Add the table, including its header row. The header names become the column list in every statement.
- 2
Name the target table
Type the table the rows should be inserted into, and pick MySQL, PostgreSQL or SQLite so identifiers are quoted correctly.
- 3
Choose your options
Decide on batched or single row inserts, whether empty cells become NULL, and whether to prepend a CREATE TABLE.
- 4
Generate and copy
Press generate, review the statements in the preview, then copy them or download a .sql file.
Related tools worth bookmarking
Sources and further reading
- RFC 4180: CSV field and quoting rulesDefines how quoted fields, embedded delimiters and escaped quotes must be read.rfc-editor.org
- PostgreSQL: INSERTOfficial reference for multi row insert syntax and conflict handling in Postgres.postgresql.org
- SQLite: INSERT syntaxThe syntax diagram SQLite actually implements, including its string literal escaping rules.sqlite.org
Frequently asked questions
Common questions about the csv to sql converter.
Yes. Single quotes inside a value are doubled, which is the standard SQL escape, and backslashes are additionally escaped when you select the MySQL dialect. That covers the failure that breaks most hand written import scripts.
Escaping here is for correctness so your own import runs cleanly. Never build application queries by concatenating values, even escaped ones. Use prepared statements with bound parameters in application code, which is the only dependable defence.
Yes, and batch mode is the right choice for that. Grouping rows into multi row inserts of a few hundred at a time cuts the number of statements the database has to parse and commit, which usually makes a large load several times faster.
Because guessing column types from a sample of rows produces schemas that break on the first value that does not fit. The generated table is a starting point you are expected to edit before applying it to anything real.
No. The parsing and statement building both happen in your browser, so nothing leaves your device. That is important here because database seed data often contains real customer records that should never touch a third party service.