SQL Formatter & Minifier
Pretty-print or minify SQL for several dialects, all locally in your browser.
Loading SQL Formatter & Minifier… If nothing happens, please enable JavaScript.
A well-formatted SQL query is far easier to read, review, and debug than the single dense line that an ORM or a quick copy-paste often produces. This formatter takes any SQL statement and re-indents it with consistent keyword casing, line breaks before major clauses, and aligned lists, so a sprawling SELECT with half a dozen joins becomes something you can actually follow. When you need the opposite, the minifier collapses all the whitespace into a single line, which is convenient for embedding a query in a config file, a log message, or a one-line shell command.
Frequently asked questions
Are my SQL queries uploaded to a server?
Which SQL dialects does it support?
What is the difference between Format and Minify?
Will formatting change what my query does?
Can it handle multiple statements at once?
Why did I get a parse error?
Does the minifier preserve string literals and comments?
Does it work offline?
About SQL Formatter & Minifier
The tool understands several SQL dialects because the rules are not identical across engines. Standard SQL covers the common ANSI syntax, while the PostgreSQL, MySQL, and SQLite options adjust how identifiers, functions, and dialect-specific keywords are recognised. Pick the dialect that matches your database, paste your statement, and click Format to reflow it or Minify to compress it. The output sits in a read-only box with a one-click copy button so you can drop the result straight back into your editor.
Formatting and minifying both happen entirely inside your browser using a bundled JavaScript library, with no network calls at any point. Your queries, including any table names, column names, or literal values they contain, never leave your device. That makes the tool safe for production schemas and sensitive data, and it keeps working offline once the page has loaded.
SQL is older than you think
SQL traces back to the early 1970s at IBM, where it grew out of research into Edgar Codd's relational model. The language was originally called SEQUEL, short for Structured English Query Language, and that is why many engineers still pronounce it 'sequel' today. The name was later shortened to SQL for trademark reasons, but the spoken form stuck.
SQL became an ANSI standard in 1986 and an ISO standard in 1987, and it has been revised many times since, adding window functions, common table expressions, JSON support, and more. Despite the shared standard, every major database adds its own extensions and quirks, which is exactly why a formatter benefits from knowing which dialect it is looking at.
That divergence is also why the same query can format slightly differently depending on the engine you target. Backtick-quoted identifiers are normal in MySQL but invalid in PostgreSQL, and functions like NOW or GETDATE differ across vendors. A dialect-aware formatter respects those differences instead of mangling them, which keeps the reflowed query both readable and correct for your specific database.