SQL Formatter Guide

What is an SQL formatter?

An SQL formatter rewrites a query into a readable layout without changing what the query is supposed to do. It inserts line breaks, normalizes indentation, spaces out operators, and usually applies a consistent style to keywords such as SELECT, FROM, JOIN, and WHERE. The raw input might be functionally fine, but hard to review when everything is crammed onto one line.

That is why developers reach for an SQL beautifier even when they already have an editor. SQL often comes from places that destroy formatting: ORM logs, stack traces, vendor docs, issue trackers, chat threads, copied migrations, and analytics tools. Being able to format SQL online is useful when you want a quick cleanup pass without opening a full database client or installing an extension.

This tool runs in the browser, so the formatting happens locally on your machine. If the query includes internal schema names, customer table names, or fragments from production debugging, that local-only workflow is a practical privacy advantage.

Any edit to the SQL or formatting options clears the current result, so you always re-run the formatter against the latest input and settings.

How to use this tool

Paste the SQL statement, script, or query fragment into the input.
Run the formatter to pretty print SQL with clearer clause boundaries and indentation.
Review the output, especially around joins, nested subqueries, and CTEs.
Copy the formatted result back into your editor, migration, docs, or pull request.
If the formatter reports a problem, fix the broken SQL text and run it again.

Common use cases

Cleaning up SQL copied from application logs where whitespace was collapsed
Reformatting long reporting queries before code review so joins and aggregates are readable
Standardizing migration snippets before saving them in version control
Making ad hoc analytics queries easier to debug when they contain multiple CTEs
Converting ORM-generated SQL into something humans can inspect
Preparing example queries for internal docs, tickets, or runbooks

Formatting vs validation

This is the distinction developers miss most often.

Formatting is about presentation. Validation is about correctness against a parser, dialect, schema, and runtime environment. A formatter may understand enough structure to place line breaks intelligently, but that does not mean it can guarantee the SQL is valid for your database.

Consider this query:

SELECT id, email
FROM app_users
WHERE created_at > NOW() - INTERVAL '7 days'
ORDER BY signup_source;

A formatter can make it clean and readable. It still cannot tell you whether app_users exists, whether signup_source is indexed, whether NOW() is the right function for your engine, or whether the account executing it has permission.

Be explicit about the limits:

Formatting does not verify syntax for every engine and version.
Formatting does not validate table names, column names, views, or functions.
Formatting does not inspect execution plans or performance.
Formatting does not prove the query is safe, idempotent, or appropriate for production.
Formatting does not prevent destructive statements from being destructive.

DROP TABLE users; is still DROP TABLE users; after pretty printing.

SQL dialect differences

There is no single universal SQL in real-world development. A Postgres SQL formatter and a MySQL SQL formatter often overlap on basic SELECT, INSERT, UPDATE, and DELETE statements, but dialect-specific details matter quickly.

Postgres often includes syntax such as:

SELECT id, payload->>'event_type' AS event_type
FROM audit_log
WHERE created_at >= NOW() - INTERVAL '1 day'
ORDER BY created_at DESC;

That combines JSON operators and interval syntax that are idiomatic in PostgreSQL. You may also see RETURNING, ILIKE, DISTINCT ON, ANY(), FILTER (WHERE ...), array literals, and casts like user_id::uuid.

MySQL has its own patterns:

SELECT `id`, `email`
FROM `users`
WHERE `deleted_at` IS NULL
ORDER BY `created_at` DESC
LIMIT 20 OFFSET 40;

Backticks, MySQL-specific functions, and features like INSERT ... ON DUPLICATE KEY UPDATE are normal there. A formatter can improve layout for both, but it does not translate syntax from one dialect to another. If a query is valid only in MySQL, formatting it will not make it valid in Postgres.

Keyword casing and style choices

One of the most visible formatter decisions is keyword casing. Some teams prefer uppercase keywords:

SELECT id, email
FROM users
WHERE is_active = TRUE;

Others prefer lowercase for everything:

select id, email
from users
where is_active = true;

The choice is mostly stylistic. Uppercase keywords create stronger visual anchors between SQL clauses, which is why many teams prefer them in longer queries. Lowercase can feel less noisy if the codebase already uses lowercase for SQL embedded in app code. The important thing is consistency, especially when queries are reviewed in diffs.

Identifier casing is a separate issue. In Postgres, unquoted identifiers are folded to lowercase. In MySQL, case sensitivity depends more on configuration and filesystem behavior. A formatter should not casually rewrite quoted identifiers because quoting can affect semantics.

Joins, subqueries, and CTEs

Formatting becomes most valuable as query structure gets more complex.

For joins, the goal is usually to keep table sources and join conditions visually distinct:

SELECT u.id, u.email, o.total
FROM users AS u
INNER JOIN orders AS o
  ON o.user_id = u.id
LEFT JOIN refunds AS r
  ON r.order_id = o.id
WHERE o.status = 'paid'
  AND r.id IS NULL;

That layout makes it obvious which predicates belong to the join and which belong to the final filter.

For subqueries, indentation helps you understand scope. A nested SELECT buried inside a WHERE EXISTS (...) clause is still readable if the nesting is consistent. Without formatting, developers often miss which conditions apply inside the subquery and which apply outside it.

CTEs are where an SQL beautifier really earns its keep. A query like this:

WITH recent_orders AS (
  SELECT user_id, SUM(total) AS revenue
  FROM orders
  WHERE created_at >= CURRENT_DATE - INTERVAL '30 days'
  GROUP BY user_id
),
active_users AS (
  SELECT id, email
  FROM users
  WHERE deleted_at IS NULL
)
SELECT au.email, ro.revenue
FROM active_users AS au
JOIN recent_orders AS ro
  ON ro.user_id = au.id
ORDER BY ro.revenue DESC;

is manageable because each block has a clear boundary. When the same query is flattened into one line, review quality drops immediately.

Common formatting pain points

Some SQL is difficult to format cleanly, even with a good tool.

Long CASE expressions can become visually tall and hard to scan.
Multi-column IN (...) lists or bulk INSERT statements create very wide output.
Vendor-specific syntax may not be tokenized perfectly by generic formatters.
Comments embedded in unusual places can force awkward line wrapping.
Dynamic SQL assembled in application code often contains placeholders that are not valid standalone SQL.

Another recurring issue is truncated SQL from logs. If your app logs only the first part of the statement, the formatter may fail because the query is literally incomplete. The problem is not the formatter; the problem is the input.

When formatting helps and when it doesn't

Use formatting when the problem is readability, reviewability, or diff quality.

Do not treat it as a replacement for:

database engine syntax checks
migration review
query plan analysis with EXPLAIN
permission review
SQL injection protections in application code
transaction and locking analysis

If you are debugging performance, a pretty query is easier to inspect, but you still need real database tooling. If you are worried about correctness, run the statement in the correct engine and environment. If you are worried about safety, review the logic, bindings, and operational context.

Troubleshooting

Why won't the SQL formatter format my query? — The input may be incomplete or malformed. Common causes include unmatched quotes, broken comments, pasted prompts from a terminal, or truncated SQL copied from logs.

Does this tool validate my SQL against PostgreSQL or MySQL? — No. It can help as a Postgres SQL formatter or MySQL SQL formatter for readability, but it does not guarantee engine-specific correctness.

Can I use this to pretty print SQL online for production queries? — Yes for readability, but not as a safety check. Formatting does not validate execution plans, permissions, side effects, or environment-specific behavior.

Why did the output change select to SELECT? — Keyword casing is a formatting convention. SQL beautifiers often normalize keywords to improve readability and consistency.

Why does a formatted query still fail in my database client? — Because formatting is not validation. The query may still reference missing objects, unsupported syntax, wrong parameter placeholders, or dialect-specific features.

Does formatting upload my SQL anywhere? — No. The tool runs in the browser, so formatting happens locally on your machine.

Will formatting change query behavior? — It should only change layout and casing. If your SQL relies on exact text assembly in application code, verify the final string carefully before using it.

Can this fix SQL injection issues or unsafe queries? — No. A formatter only changes presentation. Safe query execution still depends on parameterized queries, proper escaping rules, and careful application design.