SQL Formatter

What this tool does

SQL Formatter reformats SQL queries into clean, consistently indented statements for 20 dialects including PostgreSQL, MySQL, BigQuery, Snowflake and T-SQL. Choose how keywords, functions and data types are cased, pick a standard or tabular layout, control where AND and OR break, and set the maximum width of nested expressions, all powered by the sql-formatter library running in your browser.

A query written on one long line, or copied out of an application log with inconsistent spacing, is hard to review and easy to misread. Formatting SQL the same way every time, one clause per line, aligned joins, consistent keyword case, makes it obvious at a glance what a query selects, joins and filters, and it makes diffs in version control meaningful instead of noisy.

This tool wraps the sql-formatter library, which parses the SQL for the dialect you select rather than applying regular expressions, so dialect-specific syntax such as BigQuery backtick-quoted table names or T-SQL square-bracket identifiers is handled correctly. Keyword, function and data-type case, indent width, line layout, whether AND and OR start a new line, and the maximum width of parenthesised expressions before they wrap are all adjustable, and formatting runs entirely on your device.

How to use SQL Formatter

1. Paste a query or script, or load the Sample to see the formatter in action.
2. Pick the matching SQL dialect, such as PostgreSQL, MySQL or BigQuery, from the dropdown.
3. Set Keywords, Function names and Data types to uppercase, lowercase or kept as written.
4. Choose an indentation width and a Layout: standard, or tabular with keywords aligned left or right.
5. Decide whether AND and OR start a new line or end the previous one, and set the max width for nested expressions.
6. Review the formatted result, then copy it or download it as query.sql.

Tips for better results

• Selecting the wrong dialect is the most common source of a formatting mistake; BigQuery, Snowflake and T-SQL each quote identifiers differently.
• Tabular layout with right-aligned keywords lines up SELECT, FROM, WHERE and JOIN for queries with many columns, which some teams find easier to scan.
• A smaller expression width forces long CASE statements and subqueries to wrap sooner, which can make deeply nested logic easier to follow.
• Formatting does not change a query’s behaviour, only its layout, so it is safe to run on production SQL before a code review.

Common use cases

• Cleaning up a query pasted from a slow-query log or a database GUI’s history panel before sharing it.
• Standardising SQL style across a team before it goes into a shared repository or migration file.
• Making a large generated query, such as one built by an ORM, readable enough to debug.
• Preparing SQL snippets for documentation or a blog post with consistent indentation.

Common mistakes to avoid

• Formatting PostgreSQL-specific syntax such as dollar-quoted function bodies with the generic Standard SQL dialect, which can misread the quoting.
• Assuming uppercase keywords are required; it is purely a style choice, and most databases are case-insensitive for keywords.
• Expecting the formatter to fix a syntax error; it needs valid SQL for the chosen dialect to parse successfully.