Skip to the tool
DevToolBench

SQL Formatter

Beautify or minify SQL, with strings and comments intact.

0 chars
Statements
0
Comments kept
0
Lines
0
Characters
0

Everything runs in your browser. Nothing you type is sent to a server.

Found a bug in this tool? Report it.

Share this tool

What the SQL formatter does

This SQL formatter takes a query that arrived as one long line — from a log, an ORM's debug output or a colleague's chat message — and lays it out with one clause per line, the body of each clause indented beneath it and every subquery pushed one level further in. It can also go the other way and minify a formatted query back to a single line. It works as an SQL beautifier for standard SQL, MySQL and PostgreSQL, and everything happens in your browser.

Under the hood it is a hand-written tokeniser rather than a pile of regular expressions. It reads strings, quoted identifiers, comments, numbers, parameters and operators first, and only then decides where the line breaks go. That order is what makes it safe to format SQL query online without reading the output line by line afterwards: a keyword inside a string literal is still just text.

How to use it

  1. Paste the query, or several statements separated by semicolons, into the input.
  2. Choose the dialect the query will run on, then the keyword case and the indentation you prefer.
  3. Switch the output to minify when you need the query back on one line, for a config value or a log search. Copy the result or download it as a .sql file.

The layout it produces

Each clause keyword — SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, INSERT INTO, VALUES, UPDATE, SET, RETURNING — starts its own line, and the list that follows it is split one item per line at the commas. Joins sit inside the FROM block, each on its own line with its ON condition beside it. AND and OR start new lines in a WHERE or HAVING clause, except the AND that belongs to a BETWEEN and the ones inside a CASE expression, which stay put.

LIMIT, OFFSET and set operators such as UNION ALL start a line but keep their argument on it, because LIMIT followed by a lone number on the next line helps nobody. Function calls, IN lists and window definitions stay on one line; only a parenthesis that opens a SELECT or WITH becomes an indented block.

Keyword case is a team decision

Uppercase keywords are the long-standing convention, and they make the structure of a query easy to scan in a diff. Many teams now prefer lowercase, on the argument that syntax highlighting already does that job. The formatter supports both, plus leaving the case as typed. Only reserved words change: a column called Name or date keeps its spelling, because in some databases a quoted identifier is case-sensitive and a formatter has no business guessing.

When a sql minifier is the right tool

Minified SQL is for machines and grep. It is what you want in an environment variable, a single-line log message or a test fixture compared as a string. The minifier drops everything a parser ignores and nothing it does not: comments are kept, and a line comment keeps the line break that ends it. If you want comments gone, remove them deliberately.

Dialect differences

The dialect selector changes how the text is read, not the layout. For the details that matter in each database, the MySQL formatter covers backticks, # comments and LIMIT offset, count, and the PostgreSQL formatter covers dollar quoting, :: casts and RETURNING. If the query came wrapped in a JSON payload, unwrap it with the JSON formatter first.

Frequently asked questions

Does the formatter change what my query does?

No. It only changes the whitespace between tokens and, if you ask it to, the case of reserved keywords. String literals, quoted identifiers and comments are read as single tokens and copied through byte for byte, so a comma or a double dash inside a string is never treated as syntax.

Why does the dialect setting matter?

Because the same characters mean different things. A backtick quotes an identifier in MySQL and is meaningless elsewhere, a hash starts a comment in MySQL and is an operator in PostgreSQL, and $$ opens a string in PostgreSQL only. Formatting with the wrong dialect can split a string or a comment in the wrong place, so pick the database the query will run on.

Is it safe to paste production queries here?

The formatting runs entirely in your browser. Nothing you paste is uploaded, logged or stored, which matters when a query carries table names, customer IDs or a literal email address you would rather not hand to a third-party server.

What does minify remove, exactly?

Line breaks, indentation and any space that does not separate two tokens. It keeps comments, because a -- comment in the middle of a statement still needs its line break, and it keeps a space between two operators so that a minus followed by a negative number never collapses into --, which would turn the rest of the line into a comment.

Why is my CREATE TABLE still on one line?

Line breaks come from query clauses — SELECT, FROM, WHERE, JOIN, GROUP BY and so on — and from subqueries. Parentheses that are not a subquery, such as a column list, a function call or a table definition, are kept on one line so that a short IN list does not turn into ten lines. Long DDL is better kept in a migration file formatted by hand.

Related tools

Updated