CSV-SQL Converter

About CSV-SQL Converter

CSV-SQL Converter is a free online tool that converts between CSV files and SQL statements. Generate SQL INSERT and CREATE TABLE statements from CSV data, or export SQL query results back to CSV format—all processed locally in your browser for complete privacy.

Why convert CSV to SQL?

Converting CSV to SQL is essential for importing data into databases:

- Quickly populate database tables from spreadsheet exports
- Migrate data between different systems
- Create test data for development
- Import bulk data without manual entry
- Generate SQL scripts for version control

This tool generates properly formatted INSERT statements with automatic data type detection, making database imports fast and error-free.

What SQL output formats are available?

The tool offers three SQL output options:

1. INSERT Statements Only: Just the INSERT commands for existing tables
2. CREATE TABLE Only: Table schema definition with column types
3. CREATE + INSERT: Complete SQL script with table creation and data insertion

You can also include a DROP TABLE statement to replace existing tables safely.

How are data types detected?

The converter automatically infers SQL data types by analyzing your CSV data:

- Numeric values → REAL (for decimals) or INTEGER
- Short text (< 255 chars) → VARCHAR(255)
- Long text → TEXT
- Mixed types → TEXT (safest option)

This automatic detection works with MySQL, PostgreSQL, SQLite, and most SQL databases. You can manually adjust data types in the generated SQL if needed.

Can I convert SQL back to CSV?

Yes! The SQL to CSV mode lets you:

- Execute SQL CREATE and INSERT statements
- Run SELECT queries to filter data
- Export query results to CSV format
- Choose delimiter (comma, semicolon, tab)
- Include/exclude column headers

This is useful for exporting database dumps, sharing query results, or converting SQL backups to spreadsheet format.

Does my data leave my device?

No. All CSV-SQL conversion happens entirely in your browser using JavaScript and SQL.js (a browser-based SQL engine). Your data never leaves your machine, ensuring complete privacy for sensitive information like customer data, financial records, or confidential business data.

What if my column names have special characters?

The tool automatically sanitizes column names to ensure SQL compatibility:

- Removes special characters (replaced with underscore)
- Handles spaces (converted to underscores)
- Prevents reserved SQL keywords conflicts
- Ensures valid SQL identifiers

Example: "Employee Name (2024)" becomes "Employee_Name_2024"

This ensures your generated SQL works across all database systems without errors.

Will the generated SQL work in MySQL, Postgres and SQLite without changes?

Mostly yes for INSERTs. Schema types differ: MySQL uses VARCHAR(255), Postgres prefers TEXT, SQLite is type-less (uses INTEGER, REAL, TEXT, BLOB). The generator outputs ANSI-compatible types that all three accept. Postgres-specific features (SERIAL, JSONB, arrays) require manual editing post-generation.

How does the type-detection logic decide INTEGER vs REAL vs TEXT?

It scans up to 1000 rows of each column. If every numeric value is a whole number (Number.isInteger, no decimal point) it returns INTEGER (or INT for MySQL). If any numeric value has decimals it returns the dialect's float type: REAL (SQLite), DOUBLE PRECISION (Postgres), DOUBLE (MySQL) or FLOAT (SQL Server). Non-numeric columns become VARCHAR(255) for short strings (<255 chars) or TEXT for longer. Empty cells are ignored, and mixed-type columns fall back to TEXT for safety.

Why does my 'order' or 'select' column no longer break the SQL?

Every table and column name is now wrapped in the quoting style of your chosen dialect, so SQL reserved words like order, select or group are always safe. The tool uses `backticks` for MySQL, [square brackets] for SQL Server and "double quotes" for PostgreSQL and SQLite (ANSI). Quote characters inside a name are doubled (escaped) automatically. Spaces and special characters therefore no longer need to be stripped to keep the identifier valid.

How are NULLs, empty cells, quotes, commas and newlines handled?

When converting CSV to SQL, an empty cell becomes NULL (not an empty string), numbers stay unquoted, and text values are single-quoted with embedded apostrophes escaped by doubling ('' -> ''). When converting SQL results back to CSV, NULL becomes an empty field, and any value containing the delimiter, a double quote or a newline is wrapped in double quotes with internal quotes doubled - standard RFC 4180 CSV escaping - so embedded commas and line breaks round-trip cleanly.

Which target dialect should I pick, and what does multi-row INSERT do?

Choose the database you will import into - MySQL, PostgreSQL, SQLite or SQL Server. The dialect controls identifier quoting (backticks, brackets or double quotes) and column types (INT vs INTEGER, DOUBLE vs DOUBLE PRECISION vs FLOAT vs REAL, VARCHAR vs NVARCHAR), so the script runs as-is without manual editing. Enable Multi-row INSERT to emit batched statements - INSERT INTO t (...) VALUES (...),(...),(...); chunked at 500 rows each - which load far faster than one INSERT per row for large datasets. Leave it off for one-row-per-statement output that is easier to diff.

Can I run SELECT queries on the loaded data?

Yes. The SQL to CSV mode embeds SQL.js (a 1MB WebAssembly build of SQLite). You can paste CREATE+INSERT+SELECT scripts and the SELECT results export to CSV. Useful for filtering, joining, aggregating before exporting subsets. No data leaves the browser; the entire SQLite engine runs client-side.