SQL Formatter
Format and minify SQL across eight dialects, with readable indentation.
Formatting happens in your browser. Your query, including any table names and literal values in it, is never uploaded.
SQL arrives unreadable more often than it arrives readable. It comes out of an ORM as one enormous line, out of a log with the whitespace collapsed, out of a colleague's message pasted from somewhere that ate the newlines. Before you can reason about a query you have to be able to see its shape.
More about SQL Formatter
This formatter puts each clause on its own line and indents what belongs to it, so `SELECT`, `FROM`, `WHERE`, `GROUP BY` and `ORDER BY` line up and the joins sit where you can count them. Reading a slow query usually starts with noticing there are five joins rather than the three you remembered, and that is a great deal easier to notice when they are stacked.
Dialect matters, so it is a choice rather than a guess. PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, BigQuery and Oracle PL/SQL each have syntax the others reject — casts, quoting, functions, hints. Formatting with the wrong dialect either fails on valid SQL or quietly reshapes something it misread, so pick the database you actually run.
Invalid SQL is reported rather than mangled. A formatter that shrugs and reformats something it could not parse produces output that looks plausible and is not equivalent to what you gave it, which is worse than a clear failure. When the parse fails you get the position it failed at.
Your query stays in this page. Queries carry table names, column names and often literal values from production, which is exactly the sort of thing worth not pasting into a site that uploads.
- Clause-per-line formatting with consistent indentation
- Eight dialects, chosen explicitly rather than guessed
- Keyword case set to upper, lower or left as written
- Indent width from one to eight spaces, or tabs
- Minify to a single line for embedding in code or a log
- Invalid SQL reported with a position instead of silently reshaped
- String literals preserved exactly, including keywords inside them
How to use it
- 1Paste your SQL into the input.
- 2Pick the dialect you actually run it against.
- 3Adjust the indent and keyword case if the defaults are not your house style.
- 4Read the formatted result, or switch to minify for a single line.
- 5Copy or download the result.
Questions
Does formatting change what my query does?
No: it changes whitespace, line breaks and keyword capitalisation only. String literals are preserved exactly, so a keyword inside quotes is left alone.
Why does it reject SQL that my database accepts?
Almost always the dialect: the generic option is stricter than any real database. Pick the specific dialect you run and the syntax it supports will be recognised.
Should keywords be uppercase?
It is convention rather than a requirement, and it does make clause boundaries easier to scan. The option is there because plenty of codebases have settled the other way.
What does minify do?
It collapses the statement onto one line, which is useful for embedding a query in code or a log entry. It formats first, so an unparseable statement is reported rather than flattened.
Can it format a whole file of statements?
Yes, several statements separated by semicolons are formatted together. Very large files are capped, since a formatter runs in this page and a runaway one would freeze the tab.