🗄️ SQL Formatter
Format messy SQL into indented, readable clauses, or minify it to a single line without breaking literals.
Input chars
Output chars
Input lines
Output lines
About SQL Formatter
- • Formats SQL by adding proper indentation, line breaks, and consistent keyword casing.
- • Supports SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, and more.
- • Minify mode removes all unnecessary whitespace for compact storage or transfer.
- 🔒 Your SQL is processed entirely in your browser — nothing is sent to any server.
Related Tools
📋
⏱️
🔍
🔄
JSON Formatter
Pretty-print, minify or validate JSON and see its key count, array count, nesting depth and size before and after.
Cron Expression Generator
Build or decode five-field cron expressions with per-field modes, ready-made presets and a plain English summary.
Regex Tester
Test regex patterns live against sample text, with match positions, capture groups, named groups and flag toggles.
Diff Checker
Compare two texts line by line with inline word highlights, unified or split view and adjustable context.
Tokenising first, then laying out clauses
The formatter never treats SQL as plain text. It first walks the query character by character and emits typed tokens: whitespace, line comments, block comments, string literals, quoted identifiers, numbers, words, and the single characters for parentheses, commas, semicolons and dots. Because string literals are captured as whole tokens, a comma or the word SELECT inside quoted text is never mistaken for syntax.
Next, multi-word keywords are merged into single tokens. The formatter greedily matches phrases such as GROUP BY, ORDER BY, LEFT OUTER JOIN, INSERT INTO, DELETE FROM, NOT EXISTS and ON DUPLICATE KEY UPDATE, so they are never split across lines.
Layout then follows three keyword groups. Top-level clauses such as SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, UNION and the DDL statements start a new line at the base indent. Sub-clauses such as JOIN variants, ON, USING, CASE, WHEN, THEN, ELSE and END are indented within their clause. Logical operators AND, OR, NOT and XOR begin a new line aligned with the clause they belong to. Parenthesis depth adds further indentation.
Next, multi-word keywords are merged into single tokens. The formatter greedily matches phrases such as GROUP BY, ORDER BY, LEFT OUTER JOIN, INSERT INTO, DELETE FROM, NOT EXISTS and ON DUPLICATE KEY UPDATE, so they are never split across lines.
Layout then follows three keyword groups. Top-level clauses such as SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, UNION and the DDL statements start a new line at the base indent. Sub-clauses such as JOIN variants, ON, USING, CASE, WHEN, THEN, ELSE and END are indented within their clause. Logical operators AND, OR, NOT and XOR begin a new line aligned with the clause they belong to. Parenthesis depth adds further indentation.
Before and after on a joined query
Take this single-line input, 118 characters long:
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 and u.name like 'O''Brien%' group by u.id order by orders desc;
With keyword case set to UPPERCASE and indent set to 4 spaces, the output places SELECT on line one with its column list, FROM on its own line, LEFT JOIN indented beneath it with ON indented further, WHERE on a new line at base indent, AND on its own line aligned with the WHERE block, then GROUP BY and ORDER BY each on their own line. That turns a one-line query into roughly nine readable lines, and the counters update from 1 input line to 9 output lines.
Crucially the literal 'O''Brien%' comes through untouched, including the doubled quote that escapes the apostrophe, because the tokenizer captured it as a single string token before any casing or line breaking happened. Pressing Minify on the formatted result collapses it back to one line, removing comments and reducing runs of whitespace to single spaces.
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 and u.name like 'O''Brien%' group by u.id order by orders desc;
With keyword case set to UPPERCASE and indent set to 4 spaces, the output places SELECT on line one with its column list, FROM on its own line, LEFT JOIN indented beneath it with ON indented further, WHERE on a new line at base indent, AND on its own line aligned with the WHERE block, then GROUP BY and ORDER BY each on their own line. That turns a one-line query into roughly nine readable lines, and the counters update from 1 input line to 9 output lines.
Crucially the literal 'O''Brien%' comes through untouched, including the doubled quote that escapes the apostrophe, because the tokenizer captured it as a single string token before any casing or line breaking happened. Pressing Minify on the formatted result collapses it back to one line, removing comments and reducing runs of whitespace to single spaces.
What formatting does and does not guarantee
Formatting is cosmetic. The tool rearranges whitespace, line breaks and keyword casing; it does not validate your SQL, check that tables exist, or rewrite the query for performance. A query that fails to run will still fail to run after formatting, just more legibly. Equally, a formatted query executes identically to the original, because SQL treats runs of whitespace as a single separator outside of string literals.
Minifying has one real consequence: comments are removed. If your team relies on a comment to explain a magic number or a deliberate index hint, keep the formatted version in source control and minify only for transport. MySQL optimiser hints written in the special comment form beginning with an exclamation mark are preserved, since those affect execution.
Dialect coverage is broad rather than exact. The keyword lists cover standard SQL plus common MySQL, PostgreSQL and SQL Server constructs, so vendor-specific syntax such as unusual window frame clauses or procedural blocks may be laid out plainly rather than idiomatically. Check the output before committing it, particularly for stored procedures.
Minifying has one real consequence: comments are removed. If your team relies on a comment to explain a magic number or a deliberate index hint, keep the formatted version in source control and minify only for transport. MySQL optimiser hints written in the special comment form beginning with an exclamation mark are preserved, since those affect execution.
Dialect coverage is broad rather than exact. The keyword lists cover standard SQL plus common MySQL, PostgreSQL and SQL Server constructs, so vendor-specific syntax such as unusual window frame clauses or procedural blocks may be laid out plainly rather than idiomatically. Check the output before committing it, particularly for stored procedures.
Frequently Asked Questions
No. Only whitespace, line breaks and keyword letter case are altered, and SQL ignores those outside string literals. Identifiers inside backticks or double quotes and the contents of single-quoted strings are preserved exactly, so a formatted query returns the same results as the original.
No. The tokenizer captures each single-quoted string as one unit before any layout happens, and it handles the doubled-apostrophe escape used to write a literal quote. Text such as 'SELECT, from O''Brien' passes through unchanged rather than being treated as syntax.
Format expands the query onto multiple indented lines using your chosen keyword case and indent width. Minify collapses it to a single line, removes line and block comments, and reduces whitespace runs to one space, while leaving string literals and MySQL optimiser hints intact.
The keyword and compound-phrase lists cover standard SQL plus widely used MySQL, PostgreSQL and SQL Server syntax, including join variants, CASE expressions, UNION, window PARTITION BY and common DDL. Unusual vendor-specific or procedural syntax is still laid out, but may not be indented idiomatically.
No. Tokenising, formatting and minifying are all done in JavaScript inside your browser with no external libraries or network requests. Queries containing real table names, column names or sample values stay on your machine, which matters when working with production schemas.