Developer Tools New Tool

Free Online SQL Insert and Query Generator from CSV or JSON

Paste CSV or JSON and get INSERT statements, one multi-row statement or one per row, batched how you like. Or switch mode and build a SELECT, UPDATE or DELETE from the same columns. Quoting follows the dialect you choose, and numbers, booleans and NULL are left unquoted.

Free Forever Nothing Uploaded CSV and JSON in Runs in your browser

Free Online SQL Insert and Query Generator from CSV or JSON

Advertisement Slot (Top Banner) Google AdSense Unit • Responsive Banner

SQL Insert and Query Generator Everything happens in this tab. Nothing you paste is sent anywhere.

Your data

SQL

Job Mode Table Dialect First CSV row is the header

Inserting Statements Rows per statement Empty cell means NULL

Columns

Conditions Joined with

Order and limit ORDER BY Limit

0 rows read 0 columns 0 statements

Buy Us A Coffee

Enjoying WizTools123? Help keep our server infrastructure 100% free and open for everyone.

Buy Us A Coffee

Sponsored Content (Below Tool) Google AdSense Placement

Escaping Here Is Not the Same as Parameterising

This page writes a script. Your application must not.

The values in the output are escaped: single quotes are doubled, and for MySQL backslashes are doubled too, because MySQL treats a backslash as an escape character by default while the standard does not. That is enough for a file you are going to open, read and run yourself, which is what this page is for.

It is not enough for application code. Escaping by string manipulation has a long history of failing on character set edge cases, on values that were double-decoded somewhere upstream, and on the places people forget: an identifier, a LIMIT, an ORDER BY direction. The fix is placeholders, which never mix the value into the SQL text at all: ? or $1 or a named parameter, with the value passed separately to the driver.

So use what comes out of here as a migration, a seed file or a one-off correction you will read before running. If you catch yourself building the same string at runtime from something a user typed, stop and use a prepared statement instead. No amount of escaping in a generator makes that safe.

How to Generate SQL from CSV or JSON

A few steps, and nothing is uploaded.

Paste your data CSV with a header row, or a JSON array of objects. The format is detected, and the column names come from the header or from the object keys.

Choose the mode and the dialect INSERT from the data, or build a SELECT, UPDATE or DELETE. The dialect decides how identifiers are quoted, and the four differ.

Pick the columns and conditions Untick a column to leave it out. Conditions are built from the same list, with operators including IN, LIKE, BETWEEN and IS NULL.

Read it before you run it Copy or download the statements. Run them inside a transaction if your database has one, so a mistake can be rolled back.

What to Know About Generated SQL

Including why this is not a substitute for placeholders.

Escaping here is for a script you will read, not a substitute for parameterised queries. Values are escaped correctly for the dialect you pick, which is fine for a seed file or a migration you inspect before running. Application code that builds SQL at runtime from anything a user supplied must use placeholders instead, passing the value to the driver separately, and no generator output changes that.

Quoting differs by database and getting it wrong is silent. MySQL uses backticks, PostgreSQL and SQLite use double quotes, SQL Server uses square brackets. Worse, a double-quoted identifier in PostgreSQL is case sensitive, so "Name" and name are different columns. Pick the right dialect before you copy anything.

Types are guessed from the text, which is usually right and sometimes wrong. A bare number is written unquoted, true and false become booleans, and an empty cell becomes NULL if you leave that switch on. A value with a leading zero, such as a postcode or a product code, is kept as text on purpose, because turning 007 into 7 quietly destroys data.

It does not know your schema, so it cannot check anything. Column names come from your paste, not from the database, so a typo becomes a statement that fails at run time. It cannot tell you that a column is NOT NULL, that a date format will be rejected, or that an insert will collide with a unique key. Run it in a transaction and read the output first.

Key Features & Capabilities

What this tool does, and what it deliberately does not.

CSV or JSON in The delimiter is sniffed, and quoted fields with commas survive.

Batched inserts One multi-row statement, one per row, or batches of your size.

Query builder SELECT, UPDATE and DELETE with IN, LIKE, BETWEEN and IS NULL.

Four dialects MySQL, PostgreSQL, SQL Server and SQLite quote differently.

Types respected Numbers, booleans and NULL unquoted; leading zeros kept as text.

Nothing is uploaded Real customer rows stay in your tab. It works offline.

About the SQL Generator

Two jobs that look different turn out to share almost all their machinery. Turning a spreadsheet into INSERT statements and building a SELECT by hand both need the same three things: the column names, the right quoting for the database you are talking to, and values written so that an apostrophe in a surname does not end the string early. That is why they are one page.

The data side accepts CSV or a JSON array of objects. CSV is parsed with a real scanner rather than a split on commas, so a quoted field containing a comma or a newline survives, and the delimiter is sniffed by looking for the character that gives every row the same number of columns. Types are guessed conservatively: a bare number is a number, true and false are booleans, and anything with a leading zero stays text because it is probably a code.

The query side uses the same column list to build a SELECT, UPDATE or DELETE, with conditions, ordering and a limit written in the form your dialect expects, which for SQL Server means TOP rather than LIMIT. An UPDATE takes its SET values from the first row of your data, which sounds odd until you have had to correct one record and found it is exactly what you wanted. If an UPDATE or DELETE has no conditions, the page says so plainly, because that is the statement everybody has run by accident once.

Frequently Asked Questions

Dialects, batch size, NULL, and where escaping is not enough.

No, and that is not a hedge. Use parameterised queries in code: the value goes to the driver separately and is never part of the SQL text. Escaping in a generator is appropriate for a file you will open and read before running it, which is what this produces.

A few hundred to a thousand rows per statement is the usual sweet spot. Far fewer and you pay round-trip overhead per statement; far more and you can hit a packet size limit, such as MySQL's max_allowed_packet, or make a failure hard to locate because the whole statement rolls back together.

Most likely it has a leading zero, a space, a currency symbol or a thousands separator. Only a plain number is treated as numeric, because turning 007 into 7 or stripping a leading zero from a postcode is a silent data loss that is hard to spot later. Clean the column first if it really is numeric.

The first row of your data, using whichever columns are ticked. So a single row pasted in, plus a condition on the primary key, produces exactly the correction statement you want. If your paste has many rows, only the first is used; switch to INSERT mode if you meant to load them all.

No. Nothing is connected to a database, so the column names are whatever your header row or JSON keys say. A misspelled column produces a statement that fails when you run it, which is the honest outcome. Nothing here can warn you about a NOT NULL column, a type mismatch or a unique key collision.