How to use
- Keep a copy of the original query, especially before formatting production SQL.
- Paste the SQL statement into the input panel.
- Select the matching database dialect and choose keyword case. Open Formatting options when you need indentation or line-break controls.
- Run the formatter and review clauses, joins, conditions, comments, strings, and parentheses.
- Copy the formatted result, then validate it with the target database or SQL client before execution.
Examples
- Input
SELECT id,name FROM users WHERE active=true ORDER BY name;- Output
SELECT id, name FROM users WHERE active = true ORDER BY name;
SELECT columns and major clauses are separated for scanning.
- Input
SELECT o.id,u.name FROM orders o JOIN users u ON u.id=o.user_id WHERE o.total>100;- Output
SELECT o.id, u.name FROM orders o JOIN users u ON u.id = o.user_id WHERE o.total > 100;
JOIN and ON conditions are placed on distinct lines.
- Input
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE total>100);- Output
SELECT * FROM users WHERE id IN ( SELECT user_id FROM orders WHERE total > 100 );
Nested queries receive an additional indentation level.
Understanding the result
The output changes whitespace, line breaks, indentation, and some keyword presentation. It is intended to preserve identifiers, values, operators, and clause order.
Formatting is not SQL validation, query optimization, or execution. A readable result can still contain a syntax error, unsafe statement, or inefficient plan.
Dialect selection changes the grammar used to recognize quoted identifiers, parameters, operators, and vendor-specific keywords. It is not automatic dialect detection.
Keyword case affects recognized SQL keywords, while Preserve keeps their existing case. Tab width and logical-operator placement affect layout only.
Common errors and limitations
- Stored procedures, custom delimiters, vendor extensions, unusual operators, and dollar-quoted blocks may format differently from a database-native formatter.
- PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, and SQLite share core SQL but have different extensions. Always test the result in the target dialect.
- Formatting does not make untrusted dynamic SQL safe and does not replace parameter binding.
- Preserve the original query so you can compare tokens and restore it if a dialect-specific construct is laid out incorrectly.
Frequently asked questions
- What does a SQL formatter do?
- It parses or tokenizes SQL enough to apply consistent whitespace, indentation, and line breaks so the statement is easier to inspect.
- Does formatting change query behavior?
- It is designed to change presentation only, but every result should still be reviewed when the input uses vendor-specific or unusual syntax.
- Which SQL dialects are supported?
- The selectable grammars are Standard SQL, PostgreSQL, MySQL, MariaDB, SQL Server T-SQL, Oracle PL/SQL, and SQLite. Support does not cover every database extension.
- Does this validate or optimize SQL?
- No. Successful formatting does not prove that a statement is valid, safe, or efficient. Use the target database for syntax checks and EXPLAIN for execution planning.
- Why can a stored procedure format unexpectedly?
- Procedural extensions, custom statement delimiters, dynamic SQL, and vendor-specific blocks can exceed the formatter grammar. Keep the original and review the output.
- Is the SQL sent to a server?
- No. This formatter runs in browser JavaScript. The SQL text is not submitted to the DEA server by the formatting action.