SQL Formatter
Beautify and standardize your SQL queries for better readability across various database dialects.
Beautify and standardize your SQL queries for better readability across various database dialects.
SQL (Structured Query Language) is the standard language used to create, query, update, and manage data in relational databases. It powers everything from small application databases to massive analytics warehouses, letting you select rows, join tables together, aggregate data, and modify records with a declarative, English-like syntax.
While the core of SQL (SELECT, FROM, WHERE, JOIN, GROUP BY, etc.) is standardized, every major database engine — MySQL, PostgreSQL, SQL Server, Oracle, SQLite, BigQuery, Snowflake, Redshift, and others — adds its own dialect-specific functions, syntax extensions, and formatting conventions on top of that standard.
A SQL Formatter takes a raw or minified SQL query — often a single, hard-to-read line copied from a log file, an ORM debug output, or a database export — and rewrites it with consistent indentation, line breaks, and keyword casing so the query structure becomes easy to scan and understand.
This SQL Formatter is built on top of the widely-used sql-formatter library and supports 12 dialects, including Standard SQL, PostgreSQL, MySQL, MariaDB, SQL Server (T-SQL), SQLite, Oracle PL/SQL, DB2, Amazon Redshift, BigQuery, Snowflake, and Spark SQL. It runs entirely in your browser using a Monaco code editor with SQL syntax highlighting, so your queries are never sent to a server.
Paste a query into the input editor, type it directly, upload a .sql or .txt file, or click "Sample" to load an example query.
Select the SQL Dialect that matches your database (e.g. PostgreSQL, MySQL, SQL Server) from the Actions panel so dialect-specific syntax is handled correctly.
Choose an indentation width (2, 4, or 8 spaces) and decide whether keywords should be uppercased using the "Uppercase Keywords" checkbox.
The formatted query appears in the right-hand editor along with a Success or Syntax Error badge. If formatting fails, the error message explains what went wrong.
Use the clipboard icon or "Copy Formatted SQL" to copy the result, or "Download .sql File" to save it as a file named for the selected dialect.
Dialect-specific syntax — like SQL Server's TOP, MySQL's LIMIT, or BigQuery's backtick-quoted identifiers — can fail to parse or format incorrectly if the wrong dialect is chosen. Always match the dialect dropdown to your actual database engine.
This tool checks that SQL is syntactically well-formed enough to format — it does not verify that referenced tables/columns exist, that a JOIN condition is logically correct, or that the query will return the results you expect.
A missing closing quote around a string literal, or an unclosed /* block comment, will cause the formatter to fail with a syntax error. Check for stray quotes copied from logs or string-escaped source code.
Even after formatting, queries with many levels of nested subqueries or CTEs can remain hard to follow. Consider breaking complex logic into named CTEs (WITH clauses) before formatting for a clearer result.
Every opening ( in a function call, subquery, or condition needs a matching ). A single missing or extra parenthesis will prevent the query from being formatted.
Multiple statements separated by semicolons, or a semicolon in an unexpected place (like inside a stored procedure body), can sometimes be parsed differently depending on the dialect — check the output carefully when formatting multi-statement scripts.
Teams differ on whether SQL keywords should be uppercase (SELECT, FROM) or lowercase (select, from). Pick one convention with the "Uppercase Keywords" toggle and apply it consistently across your codebase.
A cramped one-line query with a JOIN and multiple conditions, formatted with 2-space indentation and uppercase keywords.
Input
SELECT a.id, a.name, b.order_date, b.amount FROM users a JOIN orders b ON a.id = b.user_id WHERE b.amount > 100 AND b.status = 'completed' ORDER BY b.order_date DESC LIMIT 10;
Output
SELECT a.id, a.name, b.order_date, b.amount FROM users a JOIN orders b ON a.id = b.user_id WHERE b.amount > 100 AND b.status = 'completed' ORDER BY b.order_date DESC LIMIT 10;
A report-style query joining three tables and aggregating results, beautified with 4-space indentation.
Input
SELECT c.customer_name, COUNT(o.id) AS order_count, SUM(oi.quantity * oi.price) AS total_spent FROM customers c INNER JOIN orders o ON o.customer_id = c.id INNER JOIN order_items oi ON oi.order_id = o.id WHERE o.created_at >= '2026-01-01' GROUP BY c.customer_name HAVING SUM(oi.quantity * oi.price) > 500 ORDER BY total_spent DESC;
Output
SELECT
c.customer_name,
COUNT(o.id) AS order_count,
SUM(oi.quantity * oi.price) AS total_spent
FROM
customers c
INNER JOIN orders o ON o.customer_id = c.id
INNER JOIN order_items oi ON oi.order_id = o.id
WHERE
o.created_at >= '2026-01-01'
GROUP BY
c.customer_name
HAVING
SUM(oi.quantity * oi.price) > 500
ORDER BY
total_spent DESC;A query using a correlated subquery, formatted to make the outer and inner queries visually distinct.
Input
SELECT product_id, product_name, price FROM products WHERE price > (SELECT AVG(price) FROM products WHERE category_id = 3) AND category_id = 3 ORDER BY price DESC;
Output
SELECT
product_id,
product_name,
price
FROM
products
WHERE
price > (
SELECT
AVG(price)
FROM
products
WHERE
category_id = 3
)
AND category_id = 3
ORDER BY
price DESC;No. This tool runs entirely client-side in your browser using a local SQL formatting library. Your queries, table names, and data are never sent to a server.
Standard SQL, PostgreSQL, MySQL, MariaDB, SQL Server (T-SQL), SQLite, Oracle PL/SQL, DB2, Amazon Redshift, BigQuery, Snowflake, and Spark SQL. Select the one that matches your database engine for the most accurate formatting.
It checks that your SQL is syntactically parseable, and will show a "Syntax Error" badge with a message if it cannot be formatted. It does not validate that your tables and columns exist or that the query logic produces the result you intend — that requires running it against an actual database.
This usually means the wrong dialect is selected, or the query uses vendor-specific syntax the parser doesn't recognize (e.g. proprietary hints, unusual operators). Try switching to the dialect that matches your database, or simplify the syntax that's causing the failure.
Yes. Toggle "Uppercase Keywords" in the Actions panel to format keywords like SELECT and FROM in uppercase, or leave it off to keep them lowercase.
You can choose 2, 4, or 8 spaces from the Indentation dropdown. 2 spaces is the most common convention for SQL, but pick whatever matches your team's style guide.
Yes, you can paste a script containing several semicolon-separated statements. Each statement will be formatted in place, though very unusual multi-statement or procedural syntax (stored procedures, triggers) may not format perfectly in every dialect.