Developer Tools·4 min read

How to Format SQL Queries for Review and Debugging

A query that came out of an ORM log or a BI export is technically correct and practically unreadable: one line, no breaks, aliases everywhere. Knowing how to format SQL queries turns that string back into something a colleague can review and you can debug. This guide walks through the SQL Formatter, its sixteen dialects and its layout settings, a worked before-and-after example with a JOIN, and the habits that help long queries survive code review. The tool runs in your browser, so production schema names never leave your machine.

Open the free SQL Formatter All insights

Where unreadable SQL comes from

The scenario.

ORMs log queries as single lines because machines don't need line breaks. Slow-query logs, BI export screens, and APM traces all do the same. So the day a report runs slow, what you copy out of the log is a 700-character string with every clause jammed together and aliases like t3 scattered through it.

The other source is people. A teammate pastes a query into a pull request or a Slack thread exactly as it ran, and now three reviewers are scrolling sideways through a line that never ends. Formatting is the five-second fix in both cases.

Formatting a query, setting by setting

Paste the statement into the SQL Formatter and check the three dropdowns above the panes. Dialect defaults to PostgreSQL, or to the last dialect you picked, and lists sixteen options: Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Amazon Redshift, Spark SQL, Apache Hive, Trino / Presto, SingleStoreDB, IBM Db2, and Couchbase N1QL. Keywords sets the case of SELECT, FROM and the rest: UPPERCASE by default, lowercase, or Keep as typed. Indent chooses 2 spaces, 4 spaces, or a tab. Layout switches between the standard style and two tabular styles, and AND / OR decides whether logical operators start or end a line.

Pick the dialect your query was written for and click Format. The dialect choice isn't cosmetic. The formatter genuinely parses your statement, so syntax that exists in only one grammar needs that grammar selected. If parsing fails, an error appears below the panes with a reminder to check that the dialect matches your query, instead of half-formatted output.

A JOIN query before and after formatting

Input, exactly as an ORM might log it: SELECT u.id, u.email, COUNT(o.id) AS orders FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.created_at >= '2026-01-01' GROUP BY u.id, u.email ORDER BY orders DESC;

One click later, with the default settings, the output reads like a document. Each clause keyword starts its own line, and what belongs to it sits indented two spaces underneath:

SELECT, with u.id, u.email, and COUNT(o.id) AS orders beneath it, one column per line
FROM, with users u and then LEFT JOIN orders o ON o.user_id = u.id beneath it
WHERE, with u.created_at >= '2026-01-01' beneath it
GROUP BY, with u.id and u.email beneath it
ORDER BY, with orders DESC beneath it

Why the dialect setting matters

Every database grew its own habits, and the formatter has to speak them. SQL Server wraps identifiers in square brackets, so [Order Details] parses there and nowhere else. MySQL and MariaDB use backticks for the same job. PostgreSQL brings double-colon casts and dollar-quoted strings, while BigQuery table paths like project.dataset.table arrive wrapped in backticks of their own.

Practical rule: when a query refuses to format, the dialect setting is usually wrong before the SQL is. Try the database the query actually shipped from, and only then start hunting for a genuine typo. A mismatched grammar is the most common reason a perfectly valid statement throws a parse error here.

Settling SQL style for code review

Formatted SQL changes how review conversations go. With one clause per line, comments attach to a specific join or predicate rather than to the query as a whole. Diffs shrink too: add a column and the diff shows one line, not an entire reflowed statement.

Agree on keyword case and indent width as a team, then set the dropdowns to match every time. If your codebase already has a convention you'd rather not touch, Keep as typed leaves keyword case alone and only fixes the layout. Either way, nobody wastes a review round trip on whitespace comments again.

Formatting mistakes that hide real bugs

The formatter is simple; the ways teams misuse it are predictable.

Reviewing the unformatted original because the formatter errored. Fix the dialect setting instead; unreadable SQL is where bugs go to hide.
Reformatting a colleague's query in the same commit as logic changes. The real diff drowns in whitespace noise, so format in a separate commit.
Treating a clean format as validation. The parser confirms grammar, not that the join is correct or the index exists.
Pasting production literals into tickets. Format first, then swap customer emails and ids for placeholders before sharing.

Two habits that keep long queries readable

First, format at the boundary. Whenever SQL crosses from machine territory to human territory, a log to a ticket, an ORM to a pull request, format it at that moment so nobody downstream reads the compressed version.

Second, keep the readable form in your repo. Migrations, report definitions, and analytics queries should live formatted; the database doesn't care, and every future reader does. When you ask for query help online, paste the formatted version next to your EXPLAIN output and you'll get answers that reference specific lines.

The SQL Formatter next to its neighbors

Query results usually leave the database as JSON or CSV, and those have their own pages. The JSON Formatter indents and validates API-shaped results, while the CSV to JSON Converter turns exported rows into objects when a script needs them. And if the SQL lives inside application code that's been minified, run that file through the JS Beautifier first, then bring the extracted query here.