What does the SQL formatter do?

It breaks the query at the major SQL keywords, puts each clause on its own line, and indents the parts that belong to each clause. You choose two-space or four-space indentation and whether keywords are upper-cased, and the counters underneath report the number of keywords and the input and output lengths.

Which SQL dialect does it support?

The formatting is based on the keywords common to standard SQL, so queries for PostgreSQL, MySQL, SQLite, SQL Server and Oracle all format sensibly. Dialect-specific extensions are passed through rather than specially formatted, which keeps the output faithful even where it is not ideal.

Will it change what my query does?

It changes whitespace, and whitespace outside a string literal has no meaning in SQL. The statement executes identically. That said, always run the formatted version against a non-production database first if you have modified anything by hand in the process.

Does it validate my SQL?

No. It is a text formatter, not a parser with schema knowledge. A query with a misspelled column, a missing table or a type error will format perfectly and still fail when executed. Use your database's own error messages or a linter for correctness.

Can it format a query with subqueries or CTEs?

Yes, and that is where it helps most. Nested SELECT statements and common table expressions are the queries hardest to read as a single line, and seeing them indented is often enough to understand the structure without tracing parentheses by hand.

What about queries with placeholders?

Parameter placeholders in the various styles, whether question marks, numbered or named, are treated as ordinary tokens and pass through unchanged. That means you can format a prepared statement straight out of a log without substituting values first.

Should I store formatted SQL in my codebase?

Generally yes. A formatted query reviews better, produces smaller diffs when one clause changes, and is far easier for the next person to modify safely. The argument against is only relevant where the query is generated rather than written.

Is it safe to paste a query from a production log?

Yes. The query never leaves your browser, is not stored and is not logged. This matters more than it might seem: a logged query typically exposes both your schema and whatever literal values were bound into it.

Why is my formatted output longer than the input?

Because formatting adds newlines and indentation. The character counts under the output show both, and the increase is the price of readability. If you need the compact form back, the original is still in the input box.

Is the query I paste sent to a server?

No. Formatting happens entirely in the page, and closing the tab discards the query.

SQL Formatter – Indent and Beautify SQL Queries Online

SQL Formatter

Indent

// INPUT

// OUTPUT

Paste some SQL...

// SQL Formatter: Features

Where unreadable SQL comes from

Almost never from someone writing it that way. A query logged by an application arrives as a single line because that is how logging works. A query built by an ORM is generated without regard for human readers. A query embedded in source as a string literal loses its shape when concatenated. In each case the query is correct and simply unreadable, and reformatting is the difference between understanding it in seconds and squinting at it for minutes.

What formatting reveals

Putting each clause on its own line makes structural problems visible. A join whose condition is missing stands out once the joins are stacked. A WHERE clause mixing AND and OR without parentheses shows its ambiguity once the terms are aligned. A subquery that duplicates one three lines above becomes obvious when both are indented at the same level. These are the bugs that hide in a wall of text and surface immediately in formatted output.

Keyword handling

SQL keywords are recognised and used as the points at which the query breaks into lines, so SELECT, FROM, the various JOIN forms, WHERE, GROUP BY, HAVING, ORDER BY and LIMIT each begin a new line, with conditions and column lists indented beneath. Keywords are upper-cased by default, which is the usual convention and makes the structure scan quickly; the toggle turns that off if your house style keeps them lower case. The keyword count shown under the output is a rough measure of how involved the query is.

Formatting is not validation

The formatter works on the text of the query rather than executing it, so it will happily format a statement that your database would reject. A misspelled column name, a table that does not exist or a type mismatch are all invisible here. Treat the output as a more readable version of the same text, and rely on your database or a linter for correctness.

Why a logged query is sensitive

Formatting runs as JavaScript in your browser and the query is never transmitted, stored or logged. That matters because real queries contain real information: table and column names describe your schema, and literal values in a WHERE clause are often genuine identifiers or customer data pulled from a log. All of it stays on your machine.

// SQL Formatter: FAQ

What does the SQL formatter do?: It breaks the query at the major SQL keywords, puts each clause on its own line, and indents the parts that belong to each clause. You choose two-space or four-space indentation and whether keywords are upper-cased, and the counters underneath report the number of keywords and the input and output lengths.
Which SQL dialect does it support?: The formatting is based on the keywords common to standard SQL, so queries for PostgreSQL, MySQL, SQLite, SQL Server and Oracle all format sensibly. Dialect-specific extensions are passed through rather than specially formatted, which keeps the output faithful even where it is not ideal.
Will it change what my query does?: It changes whitespace, and whitespace outside a string literal has no meaning in SQL. The statement executes identically. That said, always run the formatted version against a non-production database first if you have modified anything by hand in the process.
Does it validate my SQL?: No. It is a text formatter, not a parser with schema knowledge. A query with a misspelled column, a missing table or a type error will format perfectly and still fail when executed. Use your database's own error messages or a linter for correctness.
Can it format a query with subqueries or CTEs?: Yes, and that is where it helps most. Nested SELECT statements and common table expressions are the queries hardest to read as a single line, and seeing them indented is often enough to understand the structure without tracing parentheses by hand.
What about queries with placeholders?: Parameter placeholders in the various styles, whether question marks, numbered or named, are treated as ordinary tokens and pass through unchanged. That means you can format a prepared statement straight out of a log without substituting values first.
Should I store formatted SQL in my codebase?: Generally yes. A formatted query reviews better, produces smaller diffs when one clause changes, and is far easier for the next person to modify safely. The argument against is only relevant where the query is generated rather than written.
Is it safe to paste a query from a production log?: Yes. The query never leaves your browser, is not stored and is not logged. This matters more than it might seem: a logged query typically exposes both your schema and whatever literal values were bound into it.
Why is my formatted output longer than the input?: Because formatting adds newlines and indentation. The character counts under the output show both, and the increase is the price of readability. If you need the compact form back, the original is still in the input box.
Is the query I paste sent to a server?: No. Formatting happens entirely in the page, and closing the tab discards the query.

// How to Use SQL Formatter

Paste your query

Put the SQL into the input box. A single line pulled from an application log, generated by an ORM or extracted from a string literal in source code are the usual cases.
Choose the indentation and keyword case

Pick two or four spaces, and decide whether keywords should be upper-cased. Two spaces matches most style guides; four makes deeply nested subqueries easier to follow at a glance.
Read it, then copy

Scan the formatted output for missing join conditions and unparenthesised mixes of AND and OR, which are far easier to see once the clauses are stacked. Then copy the result into your editor or your notes.

Category Code