Turn long one-line queries into readable, properly indented SQL. Choose your dialect, keyword casing and indentation.
Everything runs in your browser — your queries are never uploaded.
The formatter tokenizes your query and re-prints it following SQL style conventions: each clause (SELECT, FROM, WHERE, JOIN, GROUP BY…) starts a new block, columns and conditions get one per line, and subqueries are indented inside their parentheses.
Dialect matters for correct tokenization of things like :: casts (PostgreSQL), #temp tables (T-SQL) or backtick identifiers (MySQL) — pick yours from the list. Keyword casing (UPPERCASE, lowercase, preserved) is applied consistently.
Use cases: reading queries extracted from logs or ORMs, cleaning up generated SQL before a code review, and making production queries debuggable. The formatter does not execute anything — it only re-prints text.
Formatting happens locally in your browser. Your queries are never sent to any server — safe even for schemas with sensitive names.
Paste the query, pick your database dialect and click Format. Long single-line queries become indented, clause-by-clause SQL you can actually read. Copy with one click.
Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, T-SQL (SQL Server), BigQuery, PL/SQL and more. The dialect mainly affects tokenizer details like casts, identifiers and temp tables.
It's style, not semantics — but UPPERCASE keywords is the most common convention because they visually separate from table/column names. Use the keyword case selector; mixed input is normalized.
It re-prints queries token-by-token but does not check them against a database, so syntax errors in values or identifiers won't be flagged. It will not execute anything.
Yes — WITH clauses, JOINs, subqueries and window functions are all indented hierarchically, which is exactly when formatting helps most.
Yes. Formatting is 100% client-side. Queries with internal table names or customer data never leave your browser.