Convert a CSV file to SQL statements locally - CREATE TABLE plus one INSERT per row, no upload.
Running locally on your device ...
Running locally on your device ...
0%
Your files never left your device
No. Everything runs in your browser - your file never leaves your device. How this is verifiable
Loading a CSV table into a real database usually means: first create a matching table, then insert every row. This tool does both steps automatically as a ready-made SQL script you can run against SQLite, PostgreSQL or MySQL.
This tool reads your CSV entirely locally in the browser (papaparse) and infers a matching type per column from the actual values: INTEGER when every cell is a whole number, REAL for decimal numbers, otherwise TEXT. A CREATE TABLE statement with those columns is produced, followed by one INSERT statement per data row - identifiers are double-quoted (ANSI standard, runs directly in SQLite and PostgreSQL), text values correctly escaped with an apostrophe.
Nothing is uploaded - the conversion even works offline. An honest note: this produces a plain, dialect-neutral data dump without a primary key, indexes or foreign-key relationships - for real schema design you add those yourself afterwards.
| Input formats | CSV |
|---|---|
| Auto-conversion | ZIP, XLSX, SQLite, DBF, VCF, ICS, DXF, GeoJSON |
| Output format | SQL |
| Batch processing | No |
| Processing | Locally in your browser (JavaScript) |
| File upload | None |
Limitations: Produces a CREATE TABLE statement plus one INSERT statement per row - no primary key, no indexes, no foreign keys. Column types (INTEGER/REAL/TEXT) are inferred from the values, not guaranteed perfect with mixed cell content. Identifiers are written ANSI-compliant in double quotes; MySQL needs its ANSI_QUOTES mode for that. Very large files need memory.
No. The SQL script is built entirely locally in the browser.
It is kept dialect-neutral and runs directly in SQLite and PostgreSQL; MySQL needs its ANSI_QUOTES mode because of the double-quoted identifiers.
From the actual values: INTEGER for whole numbers, REAL for decimal numbers, otherwise TEXT.
They are written as SQL NULL.
No, the script is a plain data dump without schema design - you add a primary key or indexes yourself.