⌘ K
sql insert → json · multi-row · typed values · live

Convert SQL INSERTs to JSON

Parse INSERT INTO … VALUES statements and emit a JSON array of records. Numbers, NULL, TRUE/FALSE and quoted strings keep their native types. Runs locally.

SQL → JSON
Input
127 B
4 lines
Output
234 B
20 lines
Status
ready
live
Ratio
1.84×
out/in
input · sql
output · json array
[
  {
    "id": 1,
    "name": "Alice",
    "age": 30,
    "active": true
  },
  {
    "id": 2,
    "name": "Bob",
    "age": 25,
    "active": false
  },
  {
    "id": 3,
    "name": "Carol",
    "age": null,
    "active": true
  }
]
Quick Start

How to convert SQL INSERTs to JSON

Each INSERT INTO `table` (cols) VALUES (…) tuple becomes one JSON object. Single- and double-quoted strings, numbers, NULL, TRUE/FALSE all map to JSON types.

  1. 01

    Paste statements

    One or many INSERT INTO statements — including the comma-separated multi-row form.

    Parsing is strict-but-tolerant — comments and trailing commas are accepted on input where the source format historically permits them; output stays canonical.

    inputstricttolerantliveparse
    input · sourcesql · live
    INSERT INTO users VALUES (1, 'A');
    loaded · parsedtarget · ready
  2. 02

    Columns + tuples

    The regex pulls out each table's column list and every VALUES tuple.

    Conversion preserves type information where the target supports it (numbers stay numeric, booleans stay boolean) so the destination parser never has to re-coerce.

    parsetype-preservinglosslesslivememoised
    cols · optionstuples · live
    cols: [id, name]
tuple: (1, 'A')
    options applied · liveround-trip
  3. 03

    Type inference

    NULL → null, TRUE/FALSE → booleans, numbers → numbers, '…' → strings.

    Re-encoding is idempotent: running output back through the same converter produces the same bytes, which keeps round-trips git-friendly.

    typesidempotentround-tripdiff-cleandeterministic
    type · convertedinfer · ready
    { "id": 1, "name": "A" }
    converted · livediff-clean
  4. 04

    Copy or download

    Use the JSON for fixtures, ETL staging, or feeding APIs.

    Copy writes via navigator.clipboard.writeText; downloads use the target’s native MIME so editors apply the right syntax highlighting on open.

    exportclipboardtarget MIMEblobclient-side
    ok · copiedready · done
    ✓ Copied
    shipped · ready to shipsuccess
Pro tips

Converting between formats, safely

Pick the strictest source format

Lossy formats hide bugs. Choose JSON or YAML as your source-of-truth, convert downstream as needed.

Round-trip in CI

If your converter is idempotent, your CI can verify A → B → A equals the original. Catches subtle data loss.

Numbers vs strings differ

YAML/TOML have a number type; CSV doesn’t. Quote IDs in CSV to keep leading-zero values intact.

Watch character encoding

Source format may be Latin-1 / Windows-1252; target should be UTF-8. Convert encoding before structure.

Preserve comments where you can

YAML and TOML support comments. Don’t silently drop them — they often encode intent.

Schema-aware beats blind

Use a schema to guide conversion. Field types, required-ness, and defaults survive better with structure.

Related toolsJSON to SQLCSV to SQLCSV to JSONXML to JSONYAML to JSONJSON Formatter
Use Cases

When to convert SQL to JSON

Seed data, test fixtures, ETL staging.

Seed fixtures

Lift INSERT dumps into JSON fixtures for unit or integration tests. Type information survives: numbers stay numeric, booleans stay boolean, strings stay strings. The destination parser doesn't have to re-coerce, which avoids the "'true' becomes "true"" bug class.

round-trip safe

ETL staging

Stage a legacy mysqldump in JSON before reshaping with jq. Run output back through the inverse converter to verify idempotent round-trips in CI. A → B → A should produce byte-identical input — if it doesn't, you've found data loss.

type-preserving

Doc samples

Show what a row looks like in docs without quoting SQL. Comments and metadata survive where the target format supports them (YAML, TOML, HCL). The tool doesn't silently drop intent-encoded annotations, which keeps your config self-documenting.

schema-aware

Mock APIs

Hand-craft response bodies from your real INSERT statements. Pair with a schema (JSON Schema, OpenAPI, Zod, Pydantic) to catch shape drift on either side. Catch breaking changes at conversion time rather than at runtime in production.

lossless

Schema discovery

See your row shape at a glance without firing up a client. Output respects target-format conventions: quoting in CSV, indent in YAML, brackets in JSON. Existing parsers don't need patches, and the result drops into legacy pipelines unchanged.

diff-clean

Cross-DB moves

Use JSON as a portable hop between MySQL, Postgres or Mongo. Encoding-aware: handles UTF-8 vs UTF-16 vs Latin-1 / Windows-1252 transparently. The character-set surprise that breaks "works on my machine" doesn't apply here.

spec-grade
FAQ

Frequently asked questions

Yes — comma-separated tuples in a single VALUES clause are flattened into one row each.
Doubled single quotes ('') unwrap to a literal apostrophe; doubled double quotes do the same for ""-quoted strings.
Yes — table and column names lose surrounding backticks or double quotes for cleaner JSON keys.
No — only literal INSERT statements. Stored procedure bodies aren't executed.
No. Parsing runs locally — nothing is uploaded.
Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

Sent straight to the maintainers · no account needed
47 in queue·8 shipped this month
Request queued. Thanks!