Toolkit
← All tools

SQL formatter

Pretty-print and indent SQL queries.

How to use the SQL formatter

  1. Paste any query — a 500-character one-liner from an ORM log, a hand-written report query, generated SQL from a BI tool.
  2. Pick the dialect. Standard SQL is the default; switch to PostgreSQL, MySQL, SQLite or SQL Server when your query uses dialect-specific syntax — [bracketed identifiers] only parse under SQL Server, `backticks` under MySQL.
  3. Click Format: each major clause (SELECT, FROM, WHERE, ORDER BY) lands on its own line, with the items under it indented two spaces, one per line.
  4. Changing the dialect re-formats the current query instantly, so you can flip through them if you're not sure which parses.
  5. Click Copy. Comments — both -- line and /* block */ — stay right where they were.

Common uses

  • Untangle machine-generated SQL: ORMs, query builders and BI tools emit single-line queries that are unreadable until formatted.
  • Standardize formatting before a code review or commit, so the diff shows logic changes rather than whitespace.
  • Debug a slow or wrong query from a log — once every JOIN and WHERE condition sits on its own line, the shape of the problem is far easier to see.
  • Make SQL presentable for documentation, a migration file, a wiki page or a Slack answer.

Tips & limitations

  • It formats — it doesn't validate or execute. Misspelled keywords like selecty pass through untouched, so a clean result is not proof the query runs.
  • A “Parse error: Unexpected …” with a line and column usually means an unclosed quote, or dialect-specific syntax under the wrong dialect setting — try the right dialect before blaming the query.
  • Keyword case is preserved, never imposed: select stays lowercase and From keeps its odd capitalization. Uppercase keywords yourself if your style guide wants them.
  • Under Standard SQL, functions the dialect doesn't recognize can pick up a stray space before the parentheses — now () instead of now(). Selecting the actual dialect (say, PostgreSQL) fixes it.
  • The output style is fixed: 2-space indent, one clause per line, expanded lists. There are no compact-mode or indent-width options on this page.

How it's built & why it's safe

Formatting uses the open-source sql-formatter library (v15, loaded from the jsDelivr CDN), which tokenizes your SQL with a dialect-aware grammar and re-prints it — nothing is ever executed. The query never leaves your browser, which matters more than it sounds: WHERE clauses routinely contain real emails, order numbers and other production data. If the library can't load you'll see a message asking you to check your connection — and your SQL still hasn't gone anywhere.

Related tools: JSON Formatter · CSV ⇄ JSON Converter · Diff Checker

Further reading: Why Toolkit runs entirely in your browser (and why that matters)

Frequently asked questions

Which SQL dialects are supported?

Standard SQL, PostgreSQL, MySQL, SQLite and SQL Server. The choice affects parsing rather than looks — bracketed identifiers, backtick quoting and dialect keywords each parse only under the right setting, while the output style stays the same.

Does it run or check my query?

Nothing is executed, ever — it's text in, text out. It doesn't check semantic validity either: unknown words pass through unchanged, and only syntax the parser can't tokenize at all, like an unclosed string, raises an error.

Why do I get a parse error on a valid query?

Usually the dialect is wrong: SQL Server brackets, MySQL backticks and other vendor syntax each need their dialect selected. The message includes a line and column; an unclosed quote earlier in the query is the other common cause.

Does it uppercase my keywords?

No — capitalization is kept exactly as typed, whether that's select, SELECT or From. The formatter only changes whitespace and line structure, so case cleanup is up to you or your linter.

Is it safe to paste production queries?

Yes — formatting happens locally in your browser, and the query text is never uploaded or stored. That includes the literal values in WHERE clauses, which often carry real customer data.

Can I change the indent width or get a compact style?

Not on this page — output is always the expanded style with 2-space indents and one item per line. If you need configurable output, the underlying sql-formatter library exposes those options when used in code.