SQL Formatter

How it works

Paste the query into the left pane; the formatted version appears in the right pane straight away. The tool moves main keywords such as SELECT, FROM, WHERE, GROUP BY, ORDER BY and JOIN onto their own lines, puts each column of the SELECT list on a line of its own and indents the AND and OR conditions inside WHERE one step; temporary tables opened with WITH (CTEs), the branches of a CASE WHEN and window functions such as ROW_NUMBER() OVER (PARTITION BY ...) each get their own level as well. A 340-character one-liner copied out of a log becomes, the moment you paste it, a layout that shows line by line which tables are joined and which conditions apply. Telling the tool which database the query belongs to makes the result more accurate: PostgreSQL's value::int casts, SQL Server's TOP 10 and [bracketed] names, MySQL's backticked names are then read by that dialect's rules. If you do not know, leave Standard SQL selected. Text inside single quotes, names in double quotes or brackets and comment lines are left untouched. The result line says how many lines became how many and which rules were applied; you can copy the output or download it as a .sql file. The collapse option does the opposite: extra spaces and line breaks are removed and the query becomes one line — for embedding in code, pasting into a field that expects a single line, or comparing against a log entry. Values in single quotes stay untouched there too, while -- line comments are turned into /* ... */, because on a single line -- would comment out everything after it and stop the query from running.

This tool is also known as sql formatter, sql to one line, sql pretty format, sql indentation online, sql query prettify, sql query pretty print, stored procedure formatter, stored procedure beautify, ssms code formatter, format sql procedure online.

What is SQL?

SQL (Structured Query Language) is the standard language for querying and manipulating relational databases; MySQL, PostgreSQL, SQL Server, Oracle and SQLite all speak dialects of it. Its core is declarative: you state what you want — which columns, from which tables, under which conditions — and the database plans how to find it. Whitespace and line breaks carry no meaning in SQL, so a query crammed onto one line and the same query carefully indented run identically. The difference exists purely for the person reading it, and that difference is what this tool produces.

What is subquery?

A subquery is a second SELECT statement embedded in parentheses inside another query; the outer query uses its result as a table or as a single value. To find everyone earning above the average, for example, the right-hand side of the WHERE condition holds a separate SELECT that computes that average. Because subqueries nest, they are the single biggest obstacle to reading a one-line query — it becomes impossible to see where each parenthesis closes. A formatter indents every subquery one level deeper, turning the nesting into a visible staircase.

What is keyword?

Keywords are SQL's own vocabulary: SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY and their relatives. They form the grammar of the language; everything else in a query is a name you chose — tables, columns and aliases. Since SQL ignores case, keywords work however they are written; uppercasing them is purely a readability convention that separates the language's words from yours at a glance. This tool applies the case conversion to keywords alone, so the spelling of your own identifiers always survives untouched.

One line or indented?

Both directions answer a real need. Indented output is for reading: opened in SSMS, DBeaver or pgAdmin, a long query shows line by line which table joins where and which conditions apply. One line is for carrying: embedding the statement in a string inside your code, pasting it into a configuration field that accepts a single line, or eyeballing two queries side by side to see whether they are the same. In those cases line breaks are only in the way.

The one real hazard in collapsing a query is the line comment. A -- comment runs to the end of its line, so the moment everything lands on one line, every statement behind it falls inside the comment and the query silently stops working. This tool does not delete the comment; it rewrites it as a /* ... */ block, so your note survives and the query stays runnable. If the note itself contains a */ sequence, that sequence is split so the comment cannot close early.

Formatting is not validation

This tool does not run the query and does not check it the way a database would: a column that does not exist, a misspelled table or a JOIN with no condition survives formatting untouched. What formatting does contribute is visibility — once the query is spread over lines, a stray parenthesis, a condition in the wrong place or a forgotten comma is suddenly easy to spot.

The scope is deliberately narrow, too. The tool is built for individual SQL statements; it separates statements ending in semicolons with a blank line, but stored procedure bodies, BEGIN…END blocks and vendor procedural dialects (PL/SQL, T-SQL control flow) are outside its job. Paste such text and the output remains runnable, but the line breaks may not land where you expect.

Should keywords be UPPERCASE or lowercase?

SQL is case-insensitive; select and SELECT run identically. Uppercase keywords are a long-standing convention for separating the language's own words from your table and column names at a glance, and most textbooks and official documentation follow it — if you do not know who will read the query, uppercase is the safe choice.

Lowercase has gained ground in codebases in recent years: editors highlight keywords anyway, so uppercase lost its distinguishing job, and lowercase is easier on the eye. What matters is applying one rule consistently across a project; the Leave-as-written option exists for fixing only the line structure without touching anyone's casing.

What does picking a dialect change?

SQL is not one language but a family of very similar ones. The core is the same everywhere, but every database has spellings of its own: PostgreSQL casts with value::int, SQL Server limits rows with TOP 10 and wraps names in [brackets], MySQL uses backticks, and in BigQuery a table name has three parts like `project.dataset.table`.

Picking the right dialect makes sure those spellings are read as names or as commands, whichever they are. The wrong choice makes no difference to most queries, but where such a spelling appears the line breaks may come out unexpectedly. If you do not know which one it is, leave Standard SQL: it knows the shared core and formats almost every everyday query correctly. If a query cannot be parsed with the dialect you chose, the tool quietly falls back to its own built-in formatter and says so in the result line — you are never left without output.

Frequently asked questions

How do I format an SQL query?

Paste it into the left pane; the version with keywords on their own lines and subqueries indented appears on the right immediately. Copy it or download it as a .sql file.

Is my query sent to a server?

No. Formatting runs entirely in your browser; the query, your table names and the values inside it are never transmitted. WHERE clauses containing real customer data are safe to paste.

Do string values and comments change?

No. Values in single quotes, identifiers in double quotes or square brackets, and -- and /* */ comments are preserved exactly; the case conversion applies to keywords only.

How do I turn an SQL query into one line?

Choose Collapse to one line in the first list; extra whitespace and line breaks disappear and the whole statement arrives on a single line in the right-hand pane. String literals are untouched, and -- line comments are converted to /* ... */ so that nothing behind them is commented out.

Can it format a stored procedure?

The tool is scoped to individual queries. BEGIN…END blocks and procedural statements are not treated specially — the output stays runnable, but the line structure may not be what you expect.

Why was my query starting with WITH (a CTE) not indented properly?

It is now. The tool puts each temporary table you open with WITH on its own level, and in two nested CTEs the second block moves one step further in. In the same way each branch of a CASE WHEN goes onto its own line, and window functions such as ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...) are opened out as well.

I do not know which dialect to pick. What happens then?

Nothing bad: Standard SQL is the default and formats almost every everyday query correctly. The dialect only matters where a spelling specific to that database appears — PostgreSQL's :: cast, SQL Server's TOP and [brackets]. If you know where the query came from, pick it from the list; if not, look at the output and, should it not be what you expected, change the dialect and try again.