- 100% client-side isolated
- no upload
- 4 tools, no signup
Make any SQL readable, portable and testable
Format, minify and convert SQL across six dialects, turn JSON or CSV into DDL and generate reproducible mock rows — free, in your browser.
- Formatter with a semantic guard
- Six dialects, gaps reported
- DDL from JSON, NDJSON or CSV
Free tools
Format it, retarget it, then fill the table
A formatter built on a real SQL tokenizer, a converter that names the constructs an engine cannot run, a converter that infers types from your data, and a seeded mock generator. No accounts, no uploads, no size paywall.
SQL Formatter
LivePretty-print a query with clause phrases on their own line, commas broken only inside a list and subqueries on their own indent — or collapse it back to one line. Keyword casing, indent width, leading or trailing commas and a line-length limit are all switches, and the token stream is compared before and after so a reformat can never rewrite the query.
Open toolDialect Converter
LiveMove one query between six engines and get the spellings that actually differ: identifier quoting, string escaping, boolean literals, type names, auto-increment columns and the LIMIT / TOP / FETCH FIRST family. What cannot be translated — ILIKE, JSONB operators, QUALIFY, ON CONFLICT — is listed as a gap instead of being silently dropped.
Open toolJSON / CSV to SQL
LivePaste an API response, one JSON object per line, or a CSV export and get a CREATE TABLE with types inferred from the values rather than declared up front: sizes come from the longest string, a date that meets a timestamp widens to a timestamp, and every substitution or renamed key is reported. The INSERT statements follow, batched or one per row.
Open toolMock Data
LivePick a preset table — users, orders, products or subscriptions — set a row count and a seed, and get rows that hold together: an email built from the same row's names, a status from a small vocabulary, dates that never read the clock. Four presets, twenty-three column kinds and one identical result per seed.
Open tool
Format a statement right here
The studio below is the full formatter: every switch that changes the layout, the line length kept under control, and a check that the token stream is identical before the result is shown.
Your SQL
Tokenized exactly as the target engine reads it.
Output
Clause phrases start a line; commas break only inside a list.
SELECT
c.id,
c.email,
count(o.id) AS orders,
sum(o.total) AS revenue
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE c.country IN ('Spain', 'Portugal', 'Italy')
AND o.status NOT IN ('cancelled', 'refunded')
AND o.placed_at >= '2024-01-01'
GROUP BY c.id,
c.email
HAVING count(o.id) > 2
ORDER BY revenue DESC
LIMIT 25;
- Statements
- 1
- Keywords
- 16
- Lines
- 1 → 15
- One line
- +1%
334 chars minified
Layout rules
Every switch changes only the layout — the token stream is compared before the result is shown.
PostgreSQL reads the formatted statement exactly like the input: 16 keywords recognised, every other token byte-identical.
Laid out in 0.00 ms on this device. Press CtrlEnter to format immediately instead of waiting for the debounce.
Moving it to another engine, or need the schema and the rows? Convert the dialect · Build the table from JSON or CSV · Generate the rows
How it works
A SQL workbench that runs in your tab
No proxy, no sign-up and nothing to wait for: the query is tokenized by your browser, the dialect conversion is computed on this device and the schema is inferred from the data you pasted. Every step is the same code path the test suite exercises.
1. Paste a query and keep its meaning
The formatter runs a real tokenizer, not a search-and-replace: strings, dollar-quoted blocks, quoted identifiers and comments are recognised before a single space moves. Clause phrases start their own line, commas break only inside a list, and the token stream is compared before and after, so a reformat that would change the query is refused rather than shipped.
2. Retarget the dialect, then read the gaps
Quoting, escaping, boolean literals, type names, auto-increment columns and the LIMIT / TOP / FETCH FIRST family are rewritten for the target engine. Constructs the target cannot run — ILIKE, JSONB operators, QUALIFY, ON CONFLICT — are listed beside the output with the reason, instead of disappearing quietly.
3. Let the data describe the schema
Paste JSON, one object per line, or a CSV export and the column types are inferred from the values: sizes come from the longest string, a date that meets a timestamp widens to a timestamp, booleans never silently become numbers, and every renamed key is reported. The DROP, CREATE TABLE and INSERTs follow in the dialect you picked.
4. Seed the table with rows you can reproduce
Mock rows come from a seeded PRNG with a fixed epoch, so the same seed always produces the same fixture — in the browser, in a test run and in a screenshot. A city never reads the clock, an email is built from the same row's names, and the output can leave as INSERTs, a full DDL script, CSV or JSON.
Privacy by architecture
Nothing is uploaded — and you can verify it
A query names tables, columns and customers, and a CSV export is the data itself. Privacy claims are cheap, so this one is falsifiable: there is no server-side path here that could receive what you paste, even if it wanted to.
No server, so nothing to log
SQLCraft ships no backend route that accepts a query. Open DevTools, watch the Network tab and use any tool: the only requests are the page assets and the social card.
Your queries stay in the tab
Statements, schemas and seeds live in React state inside this tab. They are never written to storage — the only persisted preference is the colour theme, under a key that says so.
Deterministic answers
The same input and the same options always produce the same output, and the mock generator is fixed by its seed. Nothing here depends on the current time, which is also why the server and client HTML always agree.
Free forever, no account required — the tools are static pages that run entirely on the client.
SQLCraft FAQ
Semantics, the six dialects, what the schema builder infers, and why the mock rows are reproducible.
Does formatting SQL change what the query does?
No, and that is enforced rather than promised. The formatter tokenizes the query first — strings, quoted identifiers, dollar-quoted blocks and comments are all recognised — and after laying it out it compares the token stream before and after against the same dialect keyword set. Keywords are compared case-insensitively, everything else byte for byte. If the two streams differ, the layout is not returned.
Which engines are covered?
PostgreSQL, MySQL, SQLite, SQL Server (T-SQL), Oracle and Snowflake. The dialect decides identifier quoting, string escaping, whether booleans are TRUE/FALSE or 1/0, the type names used by the DDL generator, the auto-increment idiom, and whether a row limit is written as LIMIT, TOP or FETCH FIRST.
Can I convert a query from one engine to another automatically?
The spellings that differ are rewritten for you, and the constructs that cannot be translated are listed instead of being silently dropped. LIMIT, TOP and FETCH FIRST are converted in both directions, `::` becomes CAST, backslash escapes are added or removed with the dialect, and ILIKE, JSONB operators, QUALIFY and ON CONFLICT are reported as gaps when the target engine has no equivalent.
What data shapes can become a CREATE TABLE?
An array of JSON objects, a single object, an object with a `data` array, one JSON object per line (NDJSON) and CSV are all read. Types are inferred from the values: whole numbers become integers, decimals become floats, `true`/`yes` become booleans, ISO dates and timestamps keep their distinction, and VARCHAR lengths come from the longest value rounded up.
Is the mock data really the same every time?
Yes. The generator is a seeded mulberry32 PRNG and every value — including dates, which are measured from a fixed epoch rather than the clock — is derived from that stream. The same preset, row count and seed produce byte-identical output on any machine, which makes the result usable as a fixture or a screenshot.
Is anything uploaded when I use these tools?
Nothing leaves the browser. There is no server route that accepts a query, a schema or a CSV: parsing, conversion, type inference and row generation all run in this tab. Open the Network panel with any tool open and watch — the only requests are the page assets and the social card.