SQL Formatter & Beautifier
Paste a long or messy SQL query and get it neatly indented with consistent keyword case, or minify it into one compact line. Pick your database dialect for accurate results. Your SQL never leaves your browser.
How to use the SQL Formatter & Beautifier
- Paste your SQL into the left box or press Upload .sql to open a file.
- Choose the dialect of your database so that its quoting, operators and keywords are recognised.
- Set the style: keyword case, indent and the number of blank lines between queries.
- Press Format SQL. The formatted query appears on the right and updates as you type.
- Press Minify for a compact one-line version, then Copy or Download the result.
SQL formatting conventions
Most SQL style guides, including the widely used one by Simon Holywell (sqlstyle.guide), agree on a few habits that make queries easier to scan and review:
- One clause per line: SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY and LIMIT each start a new line, so you can see the shape of the query at a glance.
- One column per line in long SELECT lists, which keeps diffs small when a column is added or removed.
- Indent sub-queries and CTE bodies one level deeper than the statement around them.
- Keywords in one case (usually uppercase) and table or column names in snake_case.
- Explicit joins: write
INNER JOIN … ONinstead of listing tables with commas and joining in WHERE.
Quoting and syntax differences between dialects
| Dialect | Quoted identifier | String escapes | Notable syntax |
|---|---|---|---|
| Standard SQL | "name" | 'it''s' | FETCH FIRST n ROWS ONLY |
| MySQL / MariaDB | `name` | 'it\'s' or 'it''s' | LIMIT n, # comments, DELIMITER in scripts |
| PostgreSQL | "name" | 'it''s', E'it\'s', $$it's$$ | :: casts, RETURNING, ILIKE |
| SQL Server (T-SQL) | [name] or "name" | 'it''s', N'…' for Unicode | TOP n, GO batch separator |
| Oracle PL/SQL | "NAME" | 'it''s', q'[it's]' | BEGIN … END; blocks, ROWNUM |
| SQLite | "name", [name], `name` | 'it''s' | Flexible typing, LIMIT n OFFSET m |
| BigQuery | `project.dataset.table` | 'it\'s', '''multi-line''' | STRUCT, ARRAY, QUALIFY |
| Snowflake | "name" | 'it''s', $$…$$ | QUALIFY, FLATTEN, semi-structured : paths |
Before and after
A one-line query copied from application logs:
select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=1 group by u.id,u.name having count(o.id)>5 order by orders descAfter formatting with uppercase keywords and a 2-space indent:
SELECT
u.id,
u.name,
count(o.id) AS orders
FROM
users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE
u.active = 1
GROUP BY
u.id,
u.name
HAVING
count(o.id) > 5
ORDER BY
orders DESCThe logic is identical, but the grouping, the join condition and the filter on the aggregate are now obvious, which makes reviewing and debugging far quicker.
Tips for long queries
- Prefer CTEs to deep nesting. A
WITHclause names each step of the logic, so a query reads from top to bottom instead of from the innermost subquery outwards. - Alias every table in a join and prefix every column with its alias, so readers never have to guess where a column comes from.
- Comment the why, not the what. A short
-- exclude test accountsabove a filter explains intent that the code cannot. - Format before you review. Running both versions of a query through the same formatter turns a confusing diff into a clear one that shows only the real changes.
Frequently asked questions
Why does the dialect matter?
Databases quote and escape differently. MySQL uses backticks for identifiers and allows backslash escapes in strings, T-SQL uses [square brackets], PostgreSQL has $$ dollar-quoted strings and :: casts, and BigQuery allows triple-quoted strings. Choosing the right dialect makes the formatter read these correctly instead of reporting an error.
Does formatting change what my query does?
No. Only whitespace, line breaks and, if you choose, the letter case of keywords are changed. Keywords are case-insensitive in SQL. Strings, quoted identifiers and comments are left exactly as written.
What does Minify do?
It removes comments and collapses all whitespace outside strings and quoted identifiers into single spaces, giving a compact one-line query that is handy for logs, code strings or URLs. Optimizer hints (/*+ … */) and MySQL version comments (/*! … */) are kept because they change behaviour.
Why do I get a parse error?
The formatter needs to understand the structure of your query. Errors usually come from a missing quote or bracket, the wrong dialect, or template placeholders such as {{name}}. The message shows the line and column where reading stopped. Fix that spot or switch dialect and try again.
Should SQL keywords be uppercase?
It is a convention, not a rule. Uppercase keywords (SELECT, FROM, WHERE) make it easy to tell keywords from table and column names, which is why most style guides use them. Some teams prefer lowercase for less visual noise; choose whichever your team uses.
Is my query sent to a server?
No. The formatting library runs in your browser after it is downloaded once from a public CDN. Your SQL, which may contain table names or data, is never uploaded.