Developer
SQL Formatter
Format, beautify, and minify SQL instantly
Why Format SQL?
Raw SQL — especially when copied from an ORM output, a query planner, or a legacy codebase — is often a wall of text with no capitalisation, inconsistent spacing, and no line breaks. Formatted SQL makes the structure of a query immediately visible: which tables are joined, what conditions are filtered, what columns are selected. This matters for:
- Code reviews — formatted SQL shows structure at a glance instead of requiring a mental parse.
- Debugging — spotting a missing JOIN condition or WHERE clause is far easier with proper indentation.
- Documentation — queries included in wikis, runbooks, and README files should always be readable.
- Version control diffs — consistently formatted SQL produces cleaner diffs with fewer noise changes.
SQL Formatting Conventions
There is no single "official" SQL style guide, but a consensus has emerged around a few conventions:
- Keywords uppercase: SELECT, FROM, WHERE, JOIN, ON, GROUP BY, ORDER BY, etc. This visually separates language keywords from identifiers (table/column names).
- Identifier case: snake_case (user_id, order_date) is standard in most databases; PascalCase is common in some .NET/SQL Server environments.
- Commas at end vs. start of line: Both are common. End-of-line commas (col1,\ncol2) are traditional; start-of-line (col1\n,col2) makes it easy to comment out a line without touching the one above.
- Indentation: 2 or 4 spaces for sub-clauses, WHERE conditions, and JOIN conditions. Tabs are rare in SQL.
- CTEs over subqueries: WITH clauses (Common Table Expressions) are far more readable than deeply nested subqueries. Most modern databases support them.
SQL Query Anatomy
Understanding the six clauses of a standard SELECT query (in execution order, not write order):
- FROM / JOIN — determines the source data and how tables are combined.
- WHERE — filters rows before aggregation.
- GROUP BY — groups rows with identical values in the specified columns.
- HAVING — filters groups (like WHERE but applied after aggregation).
- SELECT — chooses columns and applies expressions. Despite appearing first in a query, it executes near last.
- ORDER BY / LIMIT — sorts and paginates the final result set.
Writing queries in this mental execution order (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY) often makes it easier to reason about what a complex query does.
Frequently Asked Questions
What does a SQL formatter do?
A SQL formatter parses raw or minified SQL and rewrites it with consistent indentation, capitalisation, and line breaks. Formatted SQL is far easier to read, review in code diffs, and debug. This formatter also supports minification — stripping all comments and compressing whitespace into a single line, which can be useful for embedding SQL in code strings or reducing payload size in some contexts.
Will this formatter work with MySQL, PostgreSQL, SQLite, and T-SQL?
Yes. The formatter understands the core ANSI SQL keyword set that is common to all major dialects. While full dialect-specific syntax support (e.g., PostgreSQL dollar-quoting, T-SQL DECLARE blocks, MySQL backtick identifiers) is beyond what a client-side formatter can perfectly handle, the standard SELECT / INSERT / UPDATE / DELETE / CREATE / JOIN structure is formatted correctly across all common databases.
Should I write SQL keywords in uppercase or lowercase?
This is entirely a style preference, but uppercase keywords (SELECT, FROM, WHERE) are the traditional convention in SQL and remain the most common style in professional environments. They visually distinguish keywords from table and column names, improving readability. Some teams prefer fully lowercase SQL for a cleaner look, especially in ORMs and frameworks. This formatter lets you choose either style.
Does this tool send my SQL to a server?
No. All formatting happens entirely in your browser using JavaScript. Your SQL is never transmitted anywhere. This makes the tool safe to use with sensitive queries, schema definitions, or proprietary database structures.
How should I format long SQL queries in a codebase?
Best practices for SQL in code: (1) Use multi-line strings or tagged template literals to preserve readability. (2) Align SELECT columns and ON conditions vertically. (3) Place each JOIN on its own line. (4) Use CTEs (WITH clauses) to break complex queries into named, readable steps. (5) Store long queries in .sql files rather than embedding them in application code when possible.
What is the difference between pretty-print and minify?
Pretty-print (format) expands SQL into readable multi-line form with indentation and consistent casing. Minify does the opposite — stripping all comments and collapsing all whitespace into a single line. Minified SQL uses less space and may slightly reduce string parsing overhead, but it is nearly unreadable. Use minification only for storage or transmission, never for code that humans need to maintain.