Convert CSV to SQL

1. 1

   Add your CSV

   Drop a .csv, .tsv or .txt file onto the page, or open the paste box and paste CSV text directly.

2. 2

   Pick your database

   Choose MySQL, PostgreSQL, SQLite, SQL Server, Oracle or standard SQL. Quoting, escaping, type names and date literals all follow your choice.

3. 3

   Choose a statement type

   One INSERT per row, batched multi-row INSERT, CREATE TABLE, UPDATE, DELETE or MERGE. For the last three, tick the key columns the WHERE clause should match on.

4. 4

   Check the columns

   The Columns tab shows the type inferred for each column and the exact SQL type it will produce. Override any of them, rename nothing, and untick columns you do not want.

5. 5

   Generate and download

   Generate the script, then download the .sql file or copy it. Nothing is uploaded at any point.

Generate clean SQL from CSV with delimiter and encoding control, custom table naming, header mapping and fast export. Values are escaped for the database you choose, columns are given real types instead of being quoted as text, and the whole conversion runs on your device.

• Six database dialects. MySQL and MariaDB, PostgreSQL, SQLite, SQL Server, Oracle and standard SQL, each with its own quoting, escaping, type names and date literals.
• Seven statement types. One INSERT per row, batched multi-row INSERT, CREATE TABLE, DROP plus CREATE plus INSERT, UPDATE, DELETE, and MERGE or UPSERT.
• Real column types. Integers, big integers, decimals, floating point, booleans, dates, timestamps, times and sized text, inferred from every row rather than from a sample.
• A per-column override. Disagree with the inference and set the type yourself, or untick a column so it never reaches the database at all.
• NULL handling. Empty cells become NULL or an empty string, and you can name your own NULL tokens such as \N, NA or NULL.
• Safe identifiers. Reserved words, names starting with a digit, duplicate names and names too long for the database are all resolved before they can break the script.
• Two previews. A data grid showing what was parsed and which type each column became, and a live SQL preview of the statements you are about to download.
• Nothing is uploaded. The file is read, converted and written on your device, so it works offline and on mobile once the page has loaded.

The dialect is the first thing worth setting, because it changes far more than the type names. Quoting, string escaping, boolean and date literals, the identity clause and the shape of an upsert are all different, and a script written for one database is frequently invalid on another.

• MySQL and MariaDB. Identifiers in backticks, backslashes escaped inside string literals, booleans as 1 and 0, AUTO_INCREMENT, and ON DUPLICATE KEY UPDATE for upserts.
• PostgreSQL. Identifiers in double quotes, backslashes left alone because standard string literals are the default, real TRUE and FALSE, DATE and TIMESTAMP literals, identity columns and ON CONFLICT DO UPDATE.
• SQLite. Double quotes, type affinity honoured rather than invented, AUTOINCREMENT on an integer primary key, and ON CONFLICT DO UPDATE.
• SQL Server. Identifiers in square brackets, an N prefix on any literal containing non-ASCII text so accents survive, NVARCHAR columns to match, IDENTITY with the INSERT guard around it, and MERGE for upserts.
• Oracle. Double quotes, a 30-character identifier limit, TO_DATE and TO_TIMESTAMP with explicit masks so a session's date format cannot change the meaning, a PL/SQL block for a conditional drop, and MERGE against dual.
• Standard SQL. Portable ANSI syntax for anything not on the list, or as a starting point you intend to adjust.

Switching dialect never re-reads the file, so it is instant even on a large export. Change it, look at the SQL preview, and change it again until the script looks like something your client will accept.

Different jobs need different statements. Loading a fresh table is not the same job as correcting rows that already exist, and generating INSERTs for the second one is how people end up with duplicates.

• INSERT. One statement per row. The most readable output and the easiest to edit by hand or to load a few hundred rows with.
• Batched INSERT. One statement per group of rows, with the batch size under your control. Far faster to execute on a large load, and roughly half the file size.
• CREATE TABLE. The table definition on its own, with inferred types, NOT NULL where the data has no gaps, and an optional primary key.
• DROP, CREATE and INSERT. The whole script in one file: remove the old table if it exists, create it, then fill it. This is the one to use for a repeatable load.
• UPDATE. One statement per row, setting every non-key column and matching on the key columns you tick.
• DELETE. One statement per row, matched on the key columns. Useful for removing an exact list of records.
• MERGE or UPSERT. Insert the row if it is new, update it if it already exists. Written in whichever form your database actually supports.

Key columns

UPDATE, DELETE and MERGE all need to know which columns identify a row. Tick them in the Columns tab. If you tick none, the first column is used and the tool says so, because an UPDATE with no WHERE clause would rewrite every row in the table. Where a key column holds no value the statement is written as IS NULL rather than = NULL, which would never match anything.

Every cell of every row is read before a single statement is written, so the declared types describe the whole file rather than the first few thousand rows. A column becomes the narrowest type that fits everything in it, and any disagreement widens it to text rather than dropping a value.

• Integers. Up to nine digits become an integer, up to nineteen a big integer, and anything longer an exact decimal, so a twenty-digit account number is never rounded.
• Decimals and floating point. The precision and scale are taken from the widest integer part and the widest fractional part anywhere in the column, so a column holding both 1234 and 1.5 is sized to hold both. Values written in exponent form become a floating point column.
• Booleans. Only the words true, false, yes and no. See below for why 1 and 0 are not included.
• Dates and timestamps. ISO 8601 only, and the date is checked against the calendar, so 2026-02-30 stays text instead of becoming an invalid date.
• Text. Sized to the longest value in the file and rounded up to the next step, so the next import does not fail on a value one character too long.

What stays text on purpose

Four cases look like something else and are not. Guessing them is how a converter quietly destroys data while producing output that looks perfect.

• Leading zeros. 007, 01730 and 0044 are a rank, a postal code and a dialling prefix. As integers they become 7, 1730 and 44, and the zeros are gone from the database for good.
• A leading plus. +15551234567 matches an integer perfectly and is a phone number. As a number it loses the plus and its meaning.
• Ambiguous dates. 03/04/2026 is the third of April in most of the world and the fourth of March in the United States, and nothing in a CSV settles it. A whole column can be consistent under both readings for years.
• Single-letter flags. A column of t, f, y and n is a boolean convention and is also a grade, an initial and a category code. The words true, false, yes and no are unambiguous; the letters are not.

None of this is a wall. Every one of these can be set by hand in the Columns tab, and an explicit override is honoured exactly, including the single letters. The difference is that a guess is never made on your behalf. Where an override cannot be satisfied by a particular cell, that value is written as NULL and the tool tells you how many cells were affected rather than failing the script hundreds of statements later.

A missing measurement and a measurement of nothing are two different facts, and once they are both an empty string in the database nothing can tell them apart again. The old version of this tool wrote every empty cell as an empty string with no way to change it.

• Empty cells as NULL. The default, and what almost every import wants. The column is also marked as accepting NULL in the CREATE TABLE output.
• Empty cells as an empty string. For loading into an existing table whose columns are declared NOT NULL.
• Custom NULL tokens. Exports written by mysqldump use \N, and many hand-maintained sheets use NA, N/A or the literal word NULL. List whichever ones your file uses, separated by commas, and they become real NULLs.
• NULL in a key column. Written as IS NULL in a WHERE clause, never as = NULL, which is never true in SQL and would silently match no rows at all.
• Characters no database can store. Null bytes are removed and counted, because PostgreSQL rejects them outright while MySQL truncates the value at that point. You are told how many were affected rather than being handed three different wrong answers.

A spreadsheet heading is not a SQL identifier, and turning one into the other is where the previous version of this tool produced scripts that no database would accept. Four separate problems have to be solved before a name is safe to write.

• Reserved words. order, group, key, desc, from and table are ordinary column headings and every one of them is reserved. They are quoted automatically.
• Names that start with a digit. 1st and 2nd cannot be written unquoted in any dialect. They are quoted rather than mangled.
• Duplicate names. col-1 and col.1 both fold to col_1. The second one becomes col_1_2, and the check is case-insensitive because MySQL on Windows and SQL Server treat Total and total as the same column.
• Names too long for the database. Oracle allows thirty characters, PostgreSQL sixty-three, MySQL sixty-four. Long names are trimmed to fit, and any collision that trimming creates is resolved afterwards.

Two naming styles

Clean names folds a heading down to lower case letters, digits and underscores, so First Name becomes first_name and Café Total becomes cafe_total. Keep original keeps the heading exactly as you typed it and quotes it where the database requires quoting. There is deliberately no third option that skips quoting altogether, because a reserved word or a space has no unquoted spelling and the setting could only ever produce a broken script.

A CSV is how data leaves a spreadsheet and a SQL script is how it gets into a database. Turning one into the other by hand is slow and error prone, and the errors are the quiet kind.

• Seeding a database. Reference data, lookup tables and fixtures live in spreadsheets and need to arrive in a database as repeatable, reviewable statements.
• Test fixtures. A generated script can be committed alongside the code and re-run on every fresh environment.
• Migrations and one-off loads. A script can be read, edited and applied through whatever review process the database already has, which a bulk import through a GUI cannot.
• Working where an import wizard is not available. Plenty of production databases are reachable only through a SQL client, and a .sql file is the one format every client accepts.
• Correcting existing rows. UPDATE and MERGE turn a corrected spreadsheet into the exact statements needed to bring a live table into line with it.

These settings control how the file is read, before any SQL is written. Changing one of them re-reads the file; everything else only re-shapes the output.

• Delimiter. Auto, comma, semicolon, tab or pipe. Auto parses a sample with each candidate and picks the one that produces the most consistent row widths, so a comma inside a quoted address cannot fool it.
• Quote character. Auto, double quote, single quote, or none. Files quoted with apostrophes exist, and reading them with the wrong quote character merges rows together.
• Encoding. Auto, UTF-8, UTF-16LE, UTF-16BE, Windows-1252 or ISO-8859-1. A byte-order mark in the file always wins over the dropdown, because the file stating its own encoding beats a guess.
• First row is a header. On by default. Turn it off and columns are named by position instead, and the first row is treated as data.
• Skip rows. For exports that begin with a title, a date stamp or a blank line before the real header.
• Infer column types. On by default. Turn it off and every column is written as sized text, which is what you want when loading into an existing staging table.

Leave the delimiter on Auto first. Set it by hand only when the preview shows the file being read wrongly.

• Comma. The default, and what the format is named after. Most exports from English-locale software.
• Semicolon. What Excel writes in most of Europe, where the comma is the decimal separator.
• Tab. TSV files, and anything copied straight out of a spreadsheet into a text file.
• Pipe. Common in data pipelines and mainframe extracts, where the data itself may contain commas and semicolons.

The list is closed. Anything not on it is refused at the file dialog with a sentence saying what it is and where to take it, rather than being accepted and failing later.

What you can convert

• .csv with any of the four delimiters and any of the five encodings.
• .tsv tab-separated exports.
• .txt delimited text under any extension a spreadsheet happens to have written.
• Pasted text. Paste CSV straight into the page without saving a file first.

What is refused, and where to go instead

• Excel workbooks. An .xlsx or .xls is a compressed archive, not delimited text. Convert it to CSV first.
• JSON. Use the JSON to CSV tool first, then bring the result here.
• Files with an image or archive inside a .csv name. Detected from the content rather than the extension, and refused before anything is parsed.
• Empty files. Refused with a message rather than producing an empty script.

Size and batch limits

Free converts one file at a time, up to 25 MB, with every dialect, statement type, type override and NULL setting available. Pro converts up to 50 files in one run and delivers them as a single ZIP, and is bounded by what your device can handle rather than by a fixed number. Nothing about the correctness of the SQL is behind the paywall, because a script that does not run is not a premium finish.

The file is decoded, the delimiter and quote character are detected by parsing a sample and scoring how rectangular each reading turns out to be, and the rows are parsed with a scanner that understands quoted fields containing delimiters and line breaks. Every cell is then classified, and each column takes the narrowest type that fits all of its values.

The script is written in pieces and streamed straight into a file rather than assembled as one enormous block of text, which is what lets a 23 MB script be produced without the page ever stopping to respond. The preview shows the first statements immediately, so you can see what you are about to download before you download it.

Runs on your device, not our servers

There is no upload step and no server involved in the conversion. The file is read from disk into the page, converted there, and written back out as a download. Once the page has loaded you can disconnect from the network and it still works, which is the only version of a privacy claim you can check for yourself.

A 10 MB export of 104,000 rows is read, typed and written as a 23 MB SQL script in about a second, without the page ever stopping.

• CSV to JSON
• CSV to Excel
• CSV to XML
• CSV Viewer
• CSV Filter
• CSV Tools