Format, beautify, and minify SQL queries for MySQL, PostgreSQL, SQLite, and MSSQL. Choose your keyword case and get clean, readable SQL instantly in your browser.
SQL queries written on a single line, or generated by an ORM and copied out of application logs, are efficient to store and transmit but genuinely hard for a human to read and debug — clauses, joins, and conditions all run together with no visual separation. Formatting breaks a query into its logical clauses (SELECT, FROM, WHERE, GROUP BY, ORDER BY, and so on), each starting on its own line with consistent indentation, so the overall shape and intent of the query becomes obvious at a glance instead of requiring careful character-by-character reading.
This matters most when debugging a slow or incorrect query, reviewing a teammate's pull request that touches a migration file, or working through a query that involves several joins and a nested subquery — exactly the situations where a formatting mistake (a misplaced parenthesis, a JOIN condition on the wrong table) is easiest to catch visually once the structure is laid out clearly, and easiest to miss when everything is packed onto one dense line.
Standard SQL (technically ANSI SQL) defines a common core — SELECT, INSERT, UPDATE, DELETE, JOIN types, and basic data types — that every major relational database implements. Where dialects diverge is in identifier quoting (MySQL uses backticks, MSSQL uses square brackets, PostgreSQL and SQLite use double quotes), pagination syntax (MySQL and PostgreSQL use LIMIT/OFFSET, MSSQL traditionally uses TOP or OFFSET/FETCH), and a long list of dialect-specific functions and extensions (PostgreSQL's array and JSON operators, MySQL's GROUP_CONCAT, MSSQL's procedural T-SQL additions).
SQLite is notable for being intentionally permissive — it implements a large subset of standard SQL but is more relaxed about type enforcement (its 'type affinity' system is famously loose compared to strict typed columns in the other three) and omits some features like full RIGHT JOIN support in older versions. Picking the right dialect when formatting matters less for simple queries, which tend to look identical across all four, and more for queries that lean on dialect-specific functions or identifier quoting conventions.
There's no single official style guide for SQL the way there increasingly is for languages like JavaScript (Prettier) or Python (Black), but a few conventions are widely followed in practice. Keywords are almost always written in a single consistent case throughout a codebase — commonly UPPERCASE, to visually distinguish reserved words like SELECT and JOIN from identifiers like customer_id at a glance — while lowercase keywords have become more common in newer codebases influenced by application-code style conventions that favor consistent casing across a whole project.
Each major clause (SELECT, FROM, WHERE, GROUP BY, ORDER BY) typically starts a new line at the base indentation level, with items inside a clause — like selected columns, or AND/OR conditions in a WHERE clause — indented one level further and often one per line once there are more than two or three of them. Joins are usually written with the join type and ON condition together, often on their own line per join, so a query with several joins reads as a clear, scannable list rather than a dense paragraph. Consistency matters more than which specific convention a team picks — the goal is that every query in a codebase looks similar enough that a reader's eyes don't have to re-adjust to a new style every time they open a different file.
Inconsistent keyword casing — mixing SELECT with from and Where in the same query — is the most visually jarring and easiest to fix mistake, usually a side effect of a query being assembled piecemeal from copy-pasted fragments written by different people or generated by different tools. Over-indenting deeply nested subqueries without a clear visual anchor for where each subquery starts and ends is another common issue; a subquery should be clearly bracketed by its parentheses with a consistent indent step, not indented an arbitrary or inconsistent amount deeper than its parent.
Cramming a long list of columns or a long chain of AND conditions onto a single line is a frequent readability problem too — once a SELECT list or WHERE clause has more than two or three items, putting each one on its own line makes it far easier to spot a missing comma, a duplicated column, or an incorrect condition than scanning a single 200-character line. Finally, leaving in commented-out old versions of a query, or debug-only conditions, without clear delineation can confuse anyone reading the query later about which parts are actually active — if you need to keep old logic for reference, a clear comment explaining why is more useful than a silently commented-out fragment.
SQL Formatter cleans up and beautifies query text. These related developer tools cover other structured-data and text-processing tasks that often come up in the same workflow.