How to Format SQL Queries So They Are Easy to Read
4 min read
SQL copied from an application log, ORM debug panel, or monitoring tool often arrives as one long line. The SQL Formatter adds indentation and line breaks, applies a keyword case, and understands several database dialects so the query is easier to inspect.
Formatting runs fully in your browser, and the query is not uploaded. You can copy the result or download query.sql. The tool changes presentation, not the underlying database, and it does not execute the statement or prove that the query returns the intended rows.
Format before reviewing logic
A one-line query hides structure. Joins blend into filters, nested expressions are hard to match, and a missing condition can disappear in a wall of text. Formatting separates major clauses such as SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, and LIMIT so reviewers can follow the query in stages.
Readable layout is especially useful for generated SQL. ORMs may produce aliases, repeated predicates, and nested subqueries that no person would write by hand. Formatting does not simplify that SQL, but it makes repetition and unexpected joins easier to spot before you investigate performance or correctness.
Do not treat clean formatting as validation. A query can be beautifully indented and still update too many rows, use the wrong join, expose sensitive data, or perform poorly. Review the formatted result against the schema and business requirement, then test it using your normal database safeguards.
Choose the database dialect first
The Dialect menu includes Standard SQL, PostgreSQL, MySQL, SQLite, SQL Server (T-SQL), BigQuery, MariaDB, and Oracle PL/SQL. Choose the dialect that matches the system where the statement runs. Syntax for quoting, limits, functions, procedural blocks, and database-specific clauses can differ.
If you select the wrong dialect, the formatter may reject valid vendor syntax or arrange it in an unhelpful way. Standard SQL is a reasonable starting point for portable statements, but it is not a substitute for knowing the target database. Use PostgreSQL for PostgreSQL logs, T-SQL for SQL Server, and so on.
The formatter reports a parsing message when it cannot read the input. Check for a truncated log line, missing quote, copied parameter text, or unsupported syntax. If an application logs placeholders separately from values, formatting the SQL will not insert those values for you.
How to format SQL with Tools on Deck
Copy the complete statement when possible, including common table expressions and the final semicolon. Remove log prefixes that are not SQL, but keep comments if you want them in formatted output. The separate Minify mode removes line and block comments, so it should not be used when those notes matter.
- Paste the SQL into the Input - SQL panel, or select Sample to load an example.
- Under Dialect, choose Standard SQL, PostgreSQL, MySQL, SQLite, SQL Server (T-SQL), BigQuery, MariaDB, or Oracle PL/SQL.
- Under Keyword case, choose UPPER, lower, or Preserve.
- Under Indent, choose 2 spaces, 4 spaces, or Tabs.
- Select Format and review the Output panel; if the tool shows Couldn't format this SQL, correct the input or dialect.
- Use Copy to place the result on the clipboard or Download to save it as
query.sql. Use Clear when you want to reset all options.
Set keyword case and indentation consistently
UPPER makes SQL keywords visually distinct from table and column names. lower creates a quieter style that fits teams using lowercase SQL. Preserve keeps the input's existing keyword case. Pick the option that matches the repository or team convention instead of changing style from query to query.
Two spaces keep deeply nested SQL narrower. Four spaces make nesting more pronounced. Tabs allow editor-controlled display width but may look different across tools. The formatter applies the selected indentation consistently, which matters more for review than arguing that one width is universally best.
Formatting can create a large diff if an old file used another style. When reviewing a logic change, separate mechanical formatting from changed predicates or joins. The Diff Checker can compare two query versions, but read string literals and comments carefully because whitespace-only and semantic changes are not the same thing.
Use Minify for transport, not review
Minify collapses whitespace to one line and removes -- line comments and /* ... */ block comments while leaving quoted text intact. This can help when a system expects a compact statement or when you need a one-line example. It is the opposite of a code-review view.
Comment removal can discard hints, explanations, or operational warnings. Do not minify the only copy of a query. Keep a readable source version, especially for migrations, reports, or incident notes where comments explain assumptions and rollback steps.
For mixed files that include JavaScript, TypeScript, HTML, CSS, Markdown, YAML, or GraphQL rather than pure SQL, use the Code Formatter. The SQL tool is intended for SQL statements and its dialect selector should reflect the database syntax being reviewed.
Quick answers about SQL formatting
Formatting does not run the query, connect to a database, inspect a schema, or substitute actual bind parameters. It also does not promise equivalent behavior if you manually rewrite the result. Its job is to lay out the supplied SQL and apply style choices.
Use the dialect that matches production, even if a short query appears generic. Database-specific statements can contain valid syntax that another parser does not recognize. A parse error may also mean the log captured only part of the statement, so compare it with the original application output.
For review, look beyond indentation. Check join types and join conditions, WHERE filters, NULL behavior, grouping columns, ordering, limits, and the scope of UPDATE or DELETE statements. Run data-changing SQL only through the controls and transaction practices approved for your environment.