SQL Formatter — Format and Beautify SQL Queries
SQL from databases, logging tools, and APIs often arrives in a single long line — unformatted and unreadable. A SQL formatter applies consistent indentation, capitalises keywords, and adds line breaks to produce clean, readable queries. Formatted SQL is easier to understand, debug, review, and maintain. The free SQL formatter on PublicSoftTools formats any SQL query instantly, supporting MySQL, PostgreSQL, SQL Server, and SQLite dialects.
How to Format SQL
- Open the SQL formatter.
- Paste your SQL query — it can be a single minified line or partially formatted.
- Select the SQL dialect (MySQL, PostgreSQL, SQL Server, SQLite, or Standard SQL).
- Choose indentation style: 2 spaces, 4 spaces, or tabs.
- Click Format. The query is parsed and reformatted with consistent structure.
- Copy the formatted SQL. Use it in your editor, documentation, or code review.
SQL Formatting Conventions
| Convention | Example | Why it matters |
|---|---|---|
| Keywords in UPPERCASE | select → SELECT, from → FROM, where → WHERE | Standard SQL convention since the 1980s; makes keywords visually distinct from identifiers and values |
| Major clauses on new lines | SELECT ... \n FROM ... \n WHERE ... \n ORDER BY ... | Each major clause starts on its own line at the leftmost position; easier to scan which clauses a query has |
| Indentation for sub-clauses | JOIN conditions indented 2–4 spaces under the JOIN keyword | Shows hierarchical structure; JOIN ON condition is part of the JOIN, so it is indented under it |
| Subqueries indented | SELECT ... FROM (\n SELECT ... \n FROM ... \n) AS sub | Makes nesting levels visually clear; each subquery level adds one indentation level |
| Column lists on separate lines | SELECT \n col1, \n col2, \n col3 | Easy to add/remove columns without touching other lines; clear list; works well in code review diffs |
| Comma at start or end consistently | col1, \n col2 (trailing) OR \n, col1 \n, col2 (leading) | Either convention is acceptable; pick one and stick to it. Leading commas make forgetting a comma a syntax error on the comma line itself (easier to spot). |
SQL Dialect Differences
| Dialect | Identifier quoting | String syntax | Pagination | Notes |
|---|---|---|---|---|
| MySQL / MariaDB | Backticks for identifiers: `table_name` | Single or double quotes for strings | LIMIT 10 OFFSET 20 | Case-insensitive by default; backtick quoting avoids conflicts with reserved words |
| PostgreSQL | Double quotes for identifiers: "TableName" | Single quotes only for strings; E'escape' | LIMIT 10 OFFSET 20 or FETCH FIRST 10 ROWS ONLY | Case-sensitive identifier quoting; preserves case. Unquoted identifiers lowercased. |
| SQL Server (T-SQL) | Square brackets: [table name] | Single quotes for strings; N'unicode string' | TOP 10 (older) or OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY (SQL:2008) | N prefix for Unicode strings. GO is a batch separator, not SQL. GETDATE() not NOW(). |
| Oracle (PL/SQL) | Double quotes for identifiers | Single quotes; q'[alternative quoting]' for strings with apostrophes | ROWNUM (older) or FETCH FIRST 10 ROWS ONLY (Oracle 12c+) | FROM DUAL for queries without a table. SYSDATE not NOW(). Sequence.NEXTVAL for auto-increment. |
| SQLite | Double quotes, backticks, or square brackets | Single quotes for strings | LIMIT 10 OFFSET 20 | Very permissive syntax. Dynamic typing. No native boolean type. Widely used for embedded databases. |
Formatting Complex Queries
JOINs
JOINs should have the ON condition on the next line, indented under the JOIN keyword:
- SELECT e.name, d.department_name
- FROM employees e
- INNER JOIN departments d
- ON e.department_id = d.id
- WHERE e.salary > 50000;
Multiple JOINs each start on a new line, with their ON conditions indented. This makes the structure immediately readable — you can scan vertically to see all tables involved.
Subqueries
Subqueries should be indented at the next level. A subquery in the WHERE clause:
- SELECT name, salary
- FROM employees
- WHERE salary > (
- SELECT AVG(salary)
- FROM employees
- );
CASE expressions
WHEN and ELSE clauses should be indented, with END aligned with CASE:
- SELECT name,
- CASE
- WHEN salary > 80000 THEN 'Senior'
- WHEN salary > 50000 THEN 'Mid'
- ELSE 'Junior'
- END AS level
- FROM employees;
SQL Minification
The opposite of formatting — removing all unnecessary whitespace to produce compact SQL — is called SQL minification. It is used when embedding SQL in application code, configuration files, or API requests where compact size matters. The formatted SQL is the source-of-truth for development; minified SQL is for runtime efficiency (marginally).
To minify: use the SQL formatter's minify option — this removes all comments, excess whitespace, and newlines while preserving the query's meaning.
SQL Formatting in CI/CD Pipelines
For teams with many SQL files (migrations, stored procedures, views), consistent formatting can be enforced automatically:
- sqlfluff: Open-source SQL linter and formatter supporting many dialects. Can be configured per dialect, integrated with pre-commit hooks.
- prettier-plugin-sql: Prettier plugin for SQL formatting, consistent with prettier-formatted codebases.
- pgFormatter: Specifically for PostgreSQL SQL; highly configurable.
- Pre-commit hooks: Run a formatter automatically before each commit — ensures all SQL committed to version control is consistently formatted.
For one-off formatting or when working in environments without build tools, the online SQL formatter is the quickest option.
Common SQL Readability Anti-Patterns
- SELECT *: Always specify column names in production code — SELECT * fetches all columns (wasteful bandwidth) and breaks if the table schema changes.
- No table aliases: In multi-table queries, always use aliases: FROM employees e, FROM departments d — makes column references unambiguous and shorter.
- Mixing case inconsistently: select FROM Employees where SALARY > 50000 — visually chaotic. Always uppercase keywords.
- No whitespace around operators: salary>50000 → salary > 50000. Whitespace around operators aids readability.
- Inline comments explaining the obvious: Comments should explain WHY (business rule, non-obvious constraint), not WHAT (the SQL already shows what).
Common Questions
Does formatting SQL affect query performance?
No — SQL formatting (whitespace, capitalisation, newlines) has zero effect on query performance. The database parses and compiles the query logic, ignoring formatting. The formatted and minified versions of the same query have identical execution plans. Formatting is purely for human readability — a development concern, not a performance concern.
Should SQL keywords be uppercase or lowercase?
Uppercase SQL keywords (SELECT, FROM, WHERE) is the near-universal convention in professional SQL, dating from early SQL standards. The databases themselves are case-insensitive for keywords — select and SELECT are identical to the parser. Some modern style guides (particularly in data science and some ORMs) use lowercase throughout. The important principle is consistency — pick one convention for your codebase and apply it everywhere.
How do I format SQL inside application code?
SQL embedded in application code (Python, Java, JavaScript) should be formatted for readability using multi-line strings. In Python: triple-quoted strings ("""). In JavaScript: template literals (backticks). The formatted SQL can then be passed to the database driver. ORMs (SQLAlchemy, Hibernate, Sequelize) abstract SQL into code constructs — if using an ORM, write ORM-style code rather than raw SQL where possible, reserving raw SQL for complex queries that the ORM cannot express cleanly.
Format Your SQL Query
Paste any SQL — single line or multi-line — for instant formatting with consistent indentation, uppercase keywords, and readable structure.
Open SQL Formatter