SQL Formatter
Max 1 MB · Formats automatically as you type · Formats, does not validate SQL correctness
Processed entirely in your browser — nothing is sent to a server.
SQL queries are easy to write as one long line and hard to read that way — a report query with three joins and a handful of conditions quickly becomes a wall of text once every clause runs together. This tool reverses that: it pretty-prints a SQL query with consistent indentation, one major clause per line, and configurable keyword casing, or collapses it back down to a single compact line when that’s what you actually need — before pasting it into a config value, for instance, where extra whitespace isn’t welcome.
Formatting is not validation. This is worth stating plainly, since it’s the single easiest thing to misunderstand about a tool like this: formatting is about how a query looks, not whether it’s correct. This tool recognizes the shape of SQL — strings, comments, a common set of keywords, parentheses — well enough to lay it out consistently, but it doesn’t parse SQL against any real grammar, doesn’t know what tables or columns exist, and doesn’t check that a query would actually run. A query with a typo or a missing clause formats exactly as readily as a correct one. If you need to know whether a query is actually valid, run it against your database.
Formatting uppercases keywords by default (configurable to lowercase or left exactly as you typed them), and breaks the query onto multiple lines around its major clauses — SELECT, FROM, WHERE, every JOIN variant, GROUP BY, ORDER BY, HAVING. Column lists and multi-row VALUES blocks get one item per line; WHERE/HAVING conditions break onto a new line at each AND/OR. A subquery in parentheses is indented one level deeper than the query around it. Indentation is configurable between 2 spaces, 4 spaces, or a tab.
Minifying does the reverse: every token is joined back onto a single line with normalized single-space separation, and comments are stripped entirely, since a – line comment run onto one line would otherwise silently swallow the rest of the query. String literals and quoted identifiers are never touched in either direction — their contents are copied through exactly as written, even if they happen to contain text that looks like SQL keywords.
Multiple statements separated by semicolons are each formatted independently, separated by a blank line, so a migration script with several statements in a row reads as a sequence of distinct queries rather than one continuous block.
Examples
- Formatting a report query — paste a <code>SELECT</code> with an <code>INNER JOIN</code>, an <code>ON</code> condition, a <code>WHERE</code> clause, and an <code>ORDER BY</code>, all crammed onto one line from a logging tool or a colleague's Slack message, and get each clause and column back on its own indented line.
- Reviewing a migration's seed data — format a generated <code>INSERT INTO ... VALUES</code> statement with dozens of rows so each row lines up on its own line, making it easy to scan for the one row with a wrong value.
- Minifying a query before embedding it — switch to Minify mode to collapse a hand-formatted query back to one line before pasting it into a config value or a script argument where whitespace matters. For the equivalent tool when the payload is JSON or XML instead of SQL, see JSON Formatter and XML Formatter.
Frequently asked questions
Does this validate my SQL?
Is my SQL sent anywhere?
WHERE clause, a token in a comment), and none of it ever leaves your device.Which SQL dialect does this support?
SELECT, JOIN, GROUP BY, and similar) shared across MySQL, PostgreSQL, SQLite, and SQL Server, and treats anything else — a dialect-specific function name, a vendor-only keyword — as a plain identifier, which still formats correctly, just without special-cased keyword casing. Double-quoted and backtick-quoted identifiers (both common ways databases let you use a reserved word or a name with spaces as a column/table name) are both preserved exactly as written.Will formatting change the content of a string literal or comment?
WHERE name = 'SELECT * FROM' keeps that literal exactly as written, never re-cased or re-indented. Comments are preserved when formatting (moved onto their own line, since this tool rebuilds every line's spacing rather than preserving your original line breaks) but removed when minifying — a -- comment runs to the end of its line, so keeping it in the middle of a single-line minified query would silently swallow everything after it.What happens with nested subqueries?
) gets its own line when the subquery itself spans multiple lines — a simple parenthesized expression like a function call (COUNT(a, b)) stays on one line, since nothing inside it needed to break. This handles the common case well, but this tool has no real SQL grammar behind it (see the dialect question above), so a deeply nested or unusual query may not format as elegantly as dedicated SQL tooling in your database client would.