Format and beautify SQL queries online with proper indentation and uppercase keywords. Also minify SQL — free tool supporting SELECT, JOIN, WHERE, GROUP BY, and more.
SQL Formatter is a free, browser-based tool
from UseToolSuite's
Format & Convert Tools collection.
All processing happens locally on your device — your data is never uploaded to any server.
Use the tool below, then scroll down for detailed documentation, frequently asked questions, and related resources.
What is SQL Formatter?
SQL Formatter is a free online tool that beautifies and formats
SQL queries with proper indentation, line breaks, and keyword
capitalization. It transforms messy, single-line, or poorly
formatted SQL into clean, readable code that is easy to review
and debug. The tool also includes a Minify mode that strips all
unnecessary whitespace and comments to produce compact SQL for
use in scripts or configurations. All formatting runs entirely
in your browser using vanilla JavaScript with no external
libraries or server calls.
When to use it?
Use the SQL Formatter when you receive a long, single-line SQL
query from a log file, ORM debug output, or a colleague's code
and need to understand its structure. It is also helpful during
code reviews when comparing SQL changes, or when documenting
queries in technical specifications and wiki pages where
readability is essential. The minify mode is useful for
embedding SQL in application code where you want to reduce
string length.
Common use cases
Database administrators and back-end developers commonly use SQL
Formatter to clean up auto-generated queries from ORMs like
Sequelize, Prisma, or Hibernate, format complex JOIN statements
with multiple WHERE conditions for debugging, prepare readable
SQL snippets for documentation and pull request descriptions,
standardize keyword casing across team codebases, and minify
stored procedures or migration scripts for deployment. It
supports common SQL keywords including SELECT, FROM, WHERE,
JOIN, GROUP BY, ORDER BY, HAVING, INSERT, UPDATE, DELETE,
CREATE, ALTER, and DROP.
SQL formatting conventions across databases
SQL formatting styles vary across database platforms and teams. Most style guides agree on uppercase keywords (SELECT, FROM, WHERE, JOIN), consistent indentation for sub-clauses, and placing each column on its own line for complex queries. PostgreSQL developers tend to use lowercase keywords with 4-space indentation, while Oracle shops prefer uppercase with 2-space indentation. The critical principle is consistency within your codebase — pick a style and enforce it. This formatter supports multiple SQL dialects including standard SQL, PostgreSQL, MySQL, T-SQL, and PL/SQL.
Why formatted SQL matters for code review
Unformatted SQL makes code reviews significantly harder. A single-line query like SELECT a.id, b.name FROM users a JOIN orders b ON a.id = b.user_id WHERE a.active = 1 AND b.total > 100 ORDER BY b.created_at DESC LIMIT 50 obscures logic and makes it easy to miss issues. Properly formatted, each clause is visible at a glance: missing indexes become obvious, join conditions are easy to verify, and WHERE clause logic is clear. Teams that enforce SQL formatting see fewer bugs in data queries and faster onboarding for new developers.
Common table expressions are the biggest readability win in modern SQL: name each step of a transformation (WITH active_users AS (...), recent_orders AS (...)) instead of nesting subqueries three levels deep. Format each CTE’s body with full indentation, and keep the final SELECT short — reviewers then read your query as a pipeline. For JOINs, put each JOIN on its own line with its ON condition indented beneath it, and join on explicit column equality before adding filters; mixing join conditions into the WHERE clause works for inner joins but silently changes semantics for outer joins.
The keyword casing debate, settled practically
UPPERCASE keywords (SELECT, FROM, WHERE) with lowercase identifiers is the convention this formatter applies and the one most style guides recommend: keywords become visual anchors that structure the query at a glance, exactly like syntax highlighting that survives being pasted into an email, a ticket, or a log. The counter-argument — that highlighting makes casing redundant — fails everywhere SQL travels as plain text, which in practice is most places SQL travels.
One query, one shape: team standardization
Formatting pays off most when it’s uniform across a codebase: diffs shrink to real changes, review comments stop relitigating style, and copy-pasted query fragments compose cleanly. Use this tool for ad-hoc work and one-off cleanups; for repositories of SQL (dbt projects, migration folders), add an automated formatter/linter such as sqlfluff or pgFormatter to CI so the style is enforced, not requested. Adopt the formatter’s defaults wherever possible — custom configurations are maintenance debt.
A query that returns wrong results often confesses under formatting: the OR that isn’t parenthesized, the join condition hiding in WHERE, the correlated subquery referencing the wrong alias. Reformatting forces every clause onto its own line where these mistakes become visible. It’s the SQL equivalent of rubber-duck debugging — and it’s why formatting belongs before asking a colleague to look at the query.
