SQL and test data
Create INSERT statements from sample CSV or JSON
Tools to use
Preparing a few test rows can involve tedious column ordering and quoting. JSON/CSV to INSERT drafts that statement, but knows nothing about the table's types or constraints. Treat inspecting how the SQL represents your source as part of the conversion, not an optional afterthought.
Read column-to-value mapping with two JSON rows
Use table people and PostgreSQL with this JSON. id is numeric; code and name are strings; note is null in row one and empty text in row two. Generated columns are id, code, name, note, with each row mapped by key rather than its original key order.
[{"id":1,"code":"001","name":"O'Reilly","note":null},{"name":"Mina","id":2,"code":"010","note":""}](1, '001', 'O''Reilly', NULL),
(2, '010', 'Mina', '')Check doubled single quotes, preserved leading zeros and the distinction between NULL and ''. Bare numeric 001 is invalid JSON; a code needing leading zeros should be a string from the start. Correct source typing is more reliable than repairing the generated text afterward.
A missing field is not automatically DEFAULT
Columns are collected across all rows, and a missing field becomes NULL. Removing note from row two changes its empty string to NULL, not DEFAULT. Omitting a column and explicitly inserting NULL can behave differently under database defaults and constraints.
Keep missing, empty, unknown and zero distinct when the domain requires it. Age zero is not unknown age, and absent notes may differ from blank notes. Build two or three representative rows and inspect these cases before generating a large batch.
CSV fields remain strings in this converter
CSV id values 1 and 2 are read as strings: the converter does not infer numeric types. This preserves leading zeros but leaves compatibility with numeric database columns dependent on destination behavior. CSV text NULL becomes 'NULL', not JSON null.
id,code,note
1,001,NULL
2,010,""CSV quoting protects delimiters and embedded newlines; it is a different layer from SQL quoting. Use CSV inspection to confirm headers and comma-containing fields. INSERT generation cannot restore characters already damaged by incorrect decoding, so verify text and columns first.
Nested data and large integers require different care
JSON numbers are parsed without losing digits, including 18446744073709551615, but fitting a destination column is a separate question. Nested objects and arrays are rejected as SQL values rather than silently stringified or split into related tables. This is not an automatic generator for database JSON-column expressions.
Limits are 1,000 rows, 256 columns and 10,000 cells. Exceeding them is not a reason to silently discard rows and call the statement complete. Identifier characters are also restricted. Review destination types, defaults and required fields; this does not reproduce arbitrary schemas.
Generation is a draft; execution is separate
The output contains no connection and the tool never executes it. Before execution elsewhere, review environment, existing records, permissions and constraints. Identity-column rules, duplicate primary keys and foreign-key targets are not established by a successful conversion.
With two fictional rows, each input cell can be matched to its output. Check NULL, empty strings, quotes and leading zeros before scaling up. Dummy-data generation avoids copying real personal records into tests. Faster generation should leave more time for reviewing meaning before execution.
Match generated columns against the actual table contract
JSON fields id, name and note do not prove a table accepts those columns as supplied. Generated IDs may restrict explicit values; NOT NULL can reject generated NULL. Length, foreign-key and uniqueness constraints are not checked. Do not stringify everything to silence errors; reconcile source meaning with schema types. Neat SQL is not proof of database acceptance.
The tool does not define what happens on a second execution: a unique key may reject it, or duplicate rows may be inserted. Do not repeatedly paste SQL without a retry plan. Transactions, existing-data checks and conflict policy belong to the execution design. This is an INSERT draft, not an idempotent importer or migration procedure.
Use a tiny fixture containing quotes, empty strings, null and leading zeroes. Compare original values with SQL literals and explain each type decision. Two or three rows expose exchange rules more clearly than a large unreviewed export. Any execution test belongs in an authorized isolated dataset, not an experimental run against production tables.