Format SQL Queries for Readable Review

A pull request arrives with a query pasted on one line. It is 400 characters wide, it joins three tables, and the only way to review it is to scroll sideways and hope the missing AND is not the reason the report is wrong. Nobody reviews that line properly, and a query that nobody reads is a query that quietly breaks a month later.

The short version: paste the query into SQL Formatter, choose the dialect, indent and keyword case, and press Format. Each clause lands on its own line with consistent indentation, and a reviewer can read it from top to bottom in ten seconds.

A worked example

Here is a typical query as it arrives from application code:

select o.id,o.total,c.name from orders o join customers c on c.id=o.customer_id where o.status in ('paid','shipped') and o.total>:min -- only big ones and o.created_at >= '2026-01-01' order by o.total desc limit 10

With Standard SQL, a 2-space indent and UPPER keywords, the tool gives this layout. SELECT is on its own line with each column indented underneath, one per line: o.id, o.total, c.name. FROM sits alone with orders o below it, and the JOIN customers c ON c.id = o.customer_id line is indented as part of the same block. WHERE is followed by o.status IN ('paid', 'shipped') on one line, then AND o.total > :min with the comment kept at the end of its line, then AND o.created_at >= '2026-01-01'. ORDER BY has o.total DESC beneath it, and LIMIT has 10 beneath it.

Notice what happened without anything being added or removed. The spaces around = and > were added, the column list was split so a diff shows one changed column per line, and the comment -- only big ones stayed where it was. A reviewer who wants to know why the filter exists can still read the note.

The three settings

The tool has three drop-downs, and each changes only whitespace and letter case.

Dialect. The choices are Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle (PL/SQL), BigQuery and Snowflake. The dialect tells the formatter which quoting styles and keywords to expect, such as square brackets in T-SQL or dollar-quoted blocks in PostgreSQL. Pick the one your database speaks, and if the formatter complains about a word it should know, try another dialect.

Indent. Two spaces, four spaces or a tab. The same query formatted with four spaces and lower-case keywords for PostgreSQL has the same shape with deeper indents, and with a tab it uses a tab character at each level. The right choice is whatever your team already uses, so the diff does not become a whitespace argument.

Keywords. UPPER, lower or As typed. Upper case is the traditional choice and makes the clauses jump out. Lower case is common in code bases that follow a lower-case style guide. "As typed" leaves your keywords alone, which is the safe choice if you only want the line breaks.

Parameters survive

Application queries are full of placeholders, and a formatter that mangles them is useless. This tool recognises question-mark placeholders and named parameters that start with a colon, an at sign or a dollar sign, such as :min, @id or $id. In the example above :min stays exactly as typed. If a dialect does not accept one of those prefixes, the tool retries with plain positional placeholders only before it reports a problem.

Format versus Minify

Next to Format there is a Minify button. It does the opposite job: it puts the whole query on one line with the whitespace squeezed out. It is useful when you need to paste a query into a log line, a JSON string or a one-line configuration value.

The details matter here. Minify copies anything inside quotes exactly as you typed it, including single quotes, double quotes, backticks, T-SQL square brackets and PostgreSQL dollar-quoted text. A literal such as 'a -- not a comment' keeps its double space and its dashes. It removes comments, with two exceptions: optimiser hints that start with a slash, star and plus sign, and MySQL conditional comments that start with a slash, star and exclamation mark, are kept, because removing them changes what the query does. And it drops the spaces around commas, brackets and semicolons.

When Minify removes a comment, the tool says so in a small note: Minify removed the comments, and you should use Format to keep them. That is a thoughtful warning, because a comment sometimes carries the reason for a strange filter. Minify the copy that goes into the log, and keep the formatted version in the repository.

In the example above, Minify gives a single line beginning select o.id,o.total,c.name from orders o join customers c on c.id=o.customer_id where o.status in('paid','shipped') and so on, with the "-- only big ones" comment gone.

What the formatter does not do

The tool's own help says it plainly: formatting changes only whitespace and keyword case, never table names, strings or values, and it does not check that the query is valid for your database. Take that literally. A query that ends with WHERE and nothing after it still formats into tidy lines, because the formatter's job is layout, not meaning. Run the query on your database, or in a test, before you rely on it.

When the formatter really cannot read the text, it says so in a short sentence instead of a stack trace, and it clears the result box so you never mistake an old result for the new one. A query that stops in the middle of a bracket, such as select * from (select 1, gives "The query ends too early. Check for a missing closing bracket, quote or keyword at the end." A stray closing bracket gives a message that names the character and the line and column, for example "The formatter did not understand ')' (line 1, column 8)". Both are quick ways of finding the typo that made the reviewer's eyes glaze over.

Using it in a review

The formatter earns its keep in code review in three ways.

First, before you commit a query, format it in the style the team uses, so nobody has to reformat it in a later change. Second, when a colleague's query comes in as one long line, format it before you read it, and you will often spot the problem, such as an OR that should have brackets around it, within seconds. Third, to see what a change really did, format the old and the new query the same way and compare them in Diff Checker. Because each clause and column is on its own line, the diff shows only the real change rather than a whole rewritten line. There is more on comparing text in the Diff Checker guide.

If a query comes back from an API as a JSON string, JSON Formatter will tidy the surrounding document first, and you can copy the SQL out from there. The two tools sit side by side naturally.

Steps

1. Open SQL Formatter and paste the query into the SQL box.
2. Choose the dialect that matches your database.
3. Choose the indent and keyword case that your team uses.
4. Press Format and read the result from top to bottom.
5. Copy the result, or download it as a file, and commit it.
6. If you need a one-line version for a log or a config value, press Minify, and remember that comments are removed.
7. Run the query against a test database before you rely on it.

The tool is a Professional Tool with 10 trial uses a day, then a $1 day pass or the $4.99 monthly plan. Pressing Format, Minify or Copy uses a trial use, so paste the whole query first.

Common mistakes

Assuming a tidy result means a correct query. Choosing the wrong dialect and then blaming the formatter for a word it does not know. Minifying the only copy of a query and losing its comments. Formatting with a different indent from the team's and creating a noisy diff. Pasting several statements without separating them with semicolons. And putting real customer values into a query that you then share, since the formatter will keep them exactly as typed.

Summary

A query that people can read is a query that people can review. Use SQL Formatter to give every clause its own line, keep your parameters and comments intact, get a one-line version when you need one, and catch an unbalanced bracket before the reviewer does. More tools for engineers are in the security tools category.

Open SQL Formatter→

Which dialect should we test more closely? Tell us on the contact page.