Format and beautify SQL queries online free. Choose your dialect, indentation and keyword case, or minify. Runs in your browser - queries never uploaded.
Paste an unreadable query into the left pane and get properly indented, consistently cased SQL in the right pane. Pick the dialect so that dialect-specific keywords are recognised, set the indentation and keyword case to match your team’s conventions, and copy the result. A minify mode does the reverse, stripping comments and collapsing whitespace into a single line for embedding in code or a config file.
Everything happens in your browser. The queries you paste are not uploaded, not logged and not stored anywhere — which matters, because real queries contain table names, column names and sometimes literal values that describe your production schema in detail.
SQL is one of the few languages where formatting routinely changes whether a bug is visible. A query written as one long line hides how many joins it contains, which conditions belong to the ON clause versus the WHERE clause, and where a filter on a left-joined table has quietly turned that join into an inner join. Break the same query onto structured lines and those problems become obvious at a glance.
Take a compact query:
select o.id,c.name,sum(l.qty*l.price) total from orders o join customers c on c.id=o.customer_id left join order_lines l on l.order_id=o.id where o.status='shipped' and l.qty>0 group by o.id,c.name having sum(l.qty*l.price)>100 order by total desc;
Formatted, the structure — and the bug — separates out:
SELECT
o.id,
c.name,
SUM(l.qty * l.price) total
FROM
orders o
JOIN customers c ON c.id = o.customer_id
LEFT JOIN order_lines l ON l.order_id = o.id
WHERE
o.status = 'shipped'
AND l.qty > 0
GROUP BY
o.id,
c.name
HAVING
SUM(l.qty * l.price) > 100
ORDER BY
total DESC;
Now it is easy to see that AND l.qty > 0 sits in the WHERE clause and therefore discards every order with no matching line — defeating the LEFT JOIN entirely. Moving that condition into the ON clause fixes it. Nobody spots that on one line.
Consistent formatting also makes version control useful. When every query in the repository is formatted the same way, a diff shows the logic that changed rather than a wall of whitespace churn, and code review stops being an argument about layout.
| Dialect | Choose it for |
|---|---|
| Standard SQL | Portable queries, or when you are not sure — a safe default |
| PostgreSQL | Postgres, and Postgres-compatible engines such as Redshift or CockroachDB |
| MySQL | MySQL, including backtick-quoted identifiers |
| MariaDB | MariaDB, which has diverged from MySQL in places |
| SQL Server (T-SQL) | Microsoft SQL Server and Azure SQL — bracket identifiers, TOP, procedural batches |
| Oracle (PL/SQL) | Oracle and its procedural extensions |
| SQLite | SQLite, and embedded or edge databases built on it |
Picking the wrong dialect will not usually corrupt your query, but the formatter may fail to recognise a keyword and leave a clause laid out awkwardly. If output looks wrong, the dialect setting is the first thing to check.
Minification here strips comments and collapses whitespace. That is exactly what you want when embedding a query in a string literal or a configuration value, but be deliberate about it: the comments removed are often the only explanation of why a strange WHERE clause exists. Keep the formatted version in your repository as the source of truth and minify only at the point of use.
If you are moving data rather than queries, the SQL converter and CSV to JSON converter handle the translation. For other structured text, see the JSON formatter and YAML to JSON converter.
No. Formatting and minification run entirely client-side in your browser. Query text never leaves your device, so it is safe to paste queries that reveal internal schema.
Standard SQL, PostgreSQL, MySQL, MariaDB, SQL Server (T-SQL), Oracle (PL/SQL) and SQLite.
Yes. Paste a whole script; statements are formatted individually and separated by the number of blank lines you configure.
No. Only whitespace and keyword casing change. SQL keywords are case-insensitive, so uppercasing them has no effect on execution. String literals and quoted identifiers are left exactly as written.
Usually the dialect is set to something the query is not written in, or the input has a syntax error. If the SQL cannot be parsed, the tool returns your original text with an error comment attached rather than silently mangling it.
The detected query type plus counts of joins and subqueries, alongside line and character counts. It is a fast complexity check, not an execution plan — use your database’s own EXPLAIN for performance work.
Beautify keeps comments. Minify removes them, along with all extra whitespace, by design.
No fixed limit. Very large scripts are bounded only by browser memory; if you are formatting tens of thousands of lines, split the file.
A SQL formatter takes raw, unformatted SQL queries and restructures them with consistent indentation, capitalization, and line breaks for improved readability. SQL code that is difficult to read is difficult to review, debug, and maintain. Formatting transforms a dense one-line query into a clearly structured statement where clauses, joins, and conditions are visually distinct.
In production environments, SQL queries can grow to hundreds of lines with multiple joins, subqueries, CTEs (Common Table Expressions), and window functions. Without consistent formatting, these queries become a maintenance burden. A SQL formatter applies configurable style rules automatically, eliminating manual formatting effort and ensuring every team member's queries follow the same conventions.
A SQL formatter parses the query into an abstract syntax tree (AST), then reconstructs it according to formatting rules:
Keyword capitalization: SQL keywords (SELECT, FROM, WHERE, JOIN) are capitalized for visual distinction from table and column names.
Clause alignment: Each major clause starts on a new line at a consistent indentation level. Columns in SELECT lists are aligned, and JOIN conditions are indented under their respective JOIN keywords.
Before and after formatting example:
Before:
select u.id,u.name,o.total from users u inner join orders o on u.id=o.user_id where o.total>100 and u.active=1 order by o.total desc limit 10;
After:
SELECT
u.id,
u.name,
o.total
FROM users u
INNER JOIN orders o
ON u.id = o.user_id
WHERE o.total > 100
AND u.active = 1
ORDER BY o.total DESC
LIMIT 10;
Formatted SQL improves readability, maintenance, and debugging. Benefits: easier to understand complex queries (especially JOINs, subqueries), faster code reviews (teammates read formatted code quicker), catch errors visually (missing commas, parentheses), consistent style across team, easier git diffs (formatted changes are clearer), better documentation, learn SQL structure (formatting reveals query logic). Example: unformatted "SELECT a,b FROM t WHERE x=1 AND y=2" vs formatted with proper line breaks and indentation. Industry standard: uppercase keywords (SELECT, FROM, WHERE), indented subqueries and JOINs. This tool automatically formats to best practices.
Standard conventions: UPPERCASE keywords (SELECT, FROM, WHERE, JOIN, ORDER BY), lowercase or PascalCase for table/column names, indent subqueries and CASE statements, one column per line in SELECT (for long lists), JOIN conditions on separate lines, align ON/WHERE clauses, use table aliases for clarity (t1.column vs long_table_name.column), meaningful alias names. Line length: max 80-120 characters. Comments: -- for single line, /* */ for blocks. Trailing commas: after each column except last (easier to add/remove). This tool follows industry-standard SQL Style Guide with customizable options.
Structure with clear hierarchy: main SELECT at left margin, each JOIN indented one level, ON conditions indented under JOIN, subqueries indented within parentheses, CASE statements indented per clause. Example pattern: SELECT columns, FROM table1 t1, INNER JOIN table2 t2, ON t1.id = t2.id, WHERE condition. Subquery: SELECT * FROM (SELECT nested FROM inner) sub WHERE sub.x = 1. Align related clauses vertically. Use line breaks before major keywords (JOIN, WHERE, GROUP BY, HAVING, ORDER BY). This tool handles nested queries, CTEs (WITH clauses), and multiple JOINs with proper indentation.
All use ANSI SQL standard but have dialect-specific features. MySQL: LIMIT for pagination, backticks for identifiers, CONCAT() for strings. PostgreSQL: advanced types (JSON, arrays, hstore), LIMIT/OFFSET, double quotes for identifiers, RETURNING clause. SQL Server: TOP for limiting, square brackets [identifiers], GETDATE(), ISNULL(). Oracle: ROWNUM, dual table, (+) for outer joins, TO_DATE(). SQLite: limited ALTER TABLE, AUTOINCREMENT. Keywords mostly same (SELECT, JOIN, WHERE), but functions and syntax details differ. This tool recognizes major dialects and formats accordingly with appropriate syntax highlighting.
Put each column on separate line for lists >3 columns. Align columns vertically. Use trailing commas (easier to add/remove columns). Group related columns with blank lines. Add comments for complex expressions. Example: SELECT id, name, email, created_at, COUNT(orders.id) AS order_count. For calculated fields: meaningful aliases. Star (*) acceptable for ad-hoc queries but specify columns in production (future-proof against table changes). Use table aliases for clarity: t1.id vs table_with_long_name.id. This tool auto-formats column lists with proper indentation and alignment.
CTEs use WITH clause to create named temporary result sets, improving readability over nested subqueries. Syntax: WITH cte_name AS (SELECT ...) SELECT * FROM cte_name. Multiple CTEs: WITH cte1 AS (...), cte2 AS (...) SELECT .... Benefits: named intermediate results, recursive queries, better performance plans (sometimes). Format: WITH on separate line, CTE name + AS on next line, indented SELECT within parentheses, main query at same level as WITH. Recursive CTEs: WITH RECURSIVE for tree/hierarchy queries. This tool formats CTEs with proper nesting and indentation for maximum readability.
CASE statement formatting: CASE on first line, each WHEN/THEN on separate line, indented, ELSE indented same as WHEN, END aligned with CASE. Example: CASE WHEN condition1 THEN result1 WHEN condition2 THEN result2 ELSE default END AS alias. For complex conditions: break to multiple lines. Searched vs simple: CASE expression WHEN value (simple) vs CASE WHEN condition (searched). Use meaningful aliases for CASE results. Nested CASE: indent additional level. Alternative: COALESCE() for NULL handling, IIF() in SQL Server. This tool automatically indents CASE statements with proper alignment.
Spaces are recommended for consistency across editors and environments. Standard: 2 or 4 spaces per indentation level. Tabs vary by editor settings (2, 4, 8 spaces) causing alignment issues. Mix of tabs and spaces causes formatting chaos. Modern practice: configure editor to insert spaces when Tab key pressed (soft tabs). For teams: define in style guide and enforce with linters (SQLFluff, sql-formatter-cli). Git: consistent spacing prevents meaningless diffs. This tool uses 2-space indentation by default (configurable) ensuring consistent output across all users and platforms.