Developer Tools

SQL Formatter

This tool reindents SQL so a long query becomes readable — clauses on their own lines, joins aligned, nesting visible. It supports the dialect differences that matter, since PostgreSQL, MySQL and T-SQL disagree about quoting, parameter markers and a good deal of syntax, and a formatter using the wrong dialect will mangle what it does not recognise.

Runs entirely in your browser — nothing you paste is uploaded.

Dialect

Uses $1 placeholders and double-quoted identifiers.

Indent

How to

How to use the SQL Formatter

  1. 1

    Paste your query

    Type, paste, or load a .sql file. Formatting runs as you type.

  2. 2

    Choose your dialect

    Pick the database you are targeting. This affects quoting, parameter placeholders and which words are treated as keywords.

  3. 3

    Set indentation and case

    Choose an indent width and whether keywords are uppercased. Uppercase keywords are the long-standing convention and make clause boundaries easier to scan.

  4. 4

    Copy the result

    Copy the formatted query back into your editor, or download it as a file.

Examples

SQL Formatter examples

A query written on one line

Input
select a.id, b.name from a join b on a.id = b.a_id where a.active = 1
Output
SELECT a.id, b.name FROM a JOIN b ON a.id = b.a_id WHERE a.active = 1

Each clause moves to its own line and the join condition is indented under it, so the query's shape becomes visible at a glance.

A common table expression

Input
with t as (select 1) select * from t
Output
WITH t AS ( SELECT 1 ) SELECT * FROM t

The CTE body is indented inside its parentheses, which makes a chain of several CTEs — the usual reason a query becomes unreadable — possible to follow.

A dialect-specific placeholder

Input
SELECT * FROM t WHERE id = $1
Output
Formatted as PostgreSQL, $1 kept as a parameter

PostgreSQL uses $1, MySQL uses ?, and T-SQL uses @name. Choosing the wrong dialect can cause a placeholder to be misread as an operator.

Why use it

What the SQL Formatter gives you

Dialect-aware

Quoting rules, parameter markers and keyword sets differ between databases, and picking the right dialect avoids the formatter mangling syntax it does not recognise.

Makes long queries reviewable

A hundred-line query with nested subqueries becomes something a colleague can actually read in a pull request.

Literals and comments preserved

String contents and comments are kept as written, so a formatted query is identical in behaviour to the one you pasted.

Nothing is uploaded

Queries routinely contain table names, business logic and sometimes literal customer data. None of it leaves your browser.

Good to know

SQL Formatter limitations

  • This formats SQL; it does not validate it. A query with a syntax error will still be reindented.
  • It cannot connect to a database, so it cannot check that the tables or columns exist.
  • Very unusual vendor extensions may not be recognised and will be laid out conservatively.
  • Formatting does not change performance — an unreadable query and a tidy one execute identically.

Summary

SQL Formatter in short

  • Choose the dialect that matches your database, since quoting and placeholders differ.
  • Formatting changes layout only and never alters what the query does.
  • CTEs, window functions and subqueries are all indented meaningfully.
  • Uppercase keywords are conventional and make clauses easier to scan.
  • Everything runs in your browser.

FAQ

SQL Formatter questions

Does the dialect setting really matter?

Yes. Databases disagree about how identifiers are quoted, which parameter markers they use and which words are reserved. A formatter using the wrong dialect can misread a placeholder as an operator or fail to recognise a keyword.

Will formatting make my query faster?

No. Whitespace is discarded by the parser, so a formatted query and a one-line query produce exactly the same execution plan. Formatting is for the humans reading it.

Does it check my SQL is correct?

No. It lays out whatever you give it, including a query with a syntax error. Checking correctness would require knowing your schema, which means connecting to your database — something this tool deliberately never does.

Should SQL keywords be uppercase?

SQL is case-insensitive for keywords, so it is a readability convention rather than a rule. Uppercase keywords separate the structure of a query from its table and column names, which is why the convention has lasted.

Can it handle CTEs and window functions?

Yes. WITH clauses are indented inside their parentheses and window function OVER clauses are laid out on their own lines, which is where a complex analytical query usually becomes impossible to read.

Are my comments preserved?

Yes, both the double-dash line form and the slash-star block form. Comments in SQL usually explain why a filter or a join exists, so losing them during formatting would be a genuine loss.

Does it format stored procedures?

Partly. The SQL statements inside are formatted, but procedural syntax — variable declarations, loops, exception blocks — varies so much between databases that it is laid out conservatively rather than restructured.

Is there a limit on query length?

Nothing fixed. A query of a few thousand lines formats without trouble; beyond that the browser starts to feel it, since the input and output are both held in memory.

Are my queries sent to a server?

No. Formatting happens in this page. That is worth knowing, because a query pasted from a bug report often contains real identifiers, table names and occasionally literal customer data in its WHERE clause.

Discover

Related developer tools