SQL Formatter
Beautify one-line SQL with uppercase keywords and indented clauses — a lifesaver when reviewing spaghetti queries.
>_ USAGE GUIDE
Paste a one-line SQL statement and receive beautifully formatted output immediately: keywords uppercased, clauses on their own lines, columns indented and aligned — the SELECT/WHERE/JOIN structure becomes readable at a glance. The reverse direction compresses a multi-line query back to a single line for logs or string literals.
- Paste the SQL: any single or multi-line statement
- Beautify or compress: format for reading, or squash to one line for embedding
- Copy the result: ready to paste into your editor, review comment, or ticket
High-frequency uses: reviewing a colleague's spaghetti query, making sense of a long statement pulled from a slow-query log, and tidying up homework or examples. Code reviewers can paste the formatted version back into the pull request, and formatted SQL is far easier to annotate line by line when explaining an execution plan to the team. Parsing and formatting run entirely in your browser, so SQL containing real table and column names can be pasted with confidence.
>_ FAQ
Q1 · Why format SQL at all, and why uppercase the keywords?
SQL is case-insensitive and runs fine on one line — but humans have to read it. With each clause on its own line, join relationships and filter conditions stand out, which speeds up debugging, optimization, and handover. Uppercase keywords are a community convention (the counter-style is lowercase keywords with uppercase identifiers); what matters is consistency. This tool uppercases keywords by default so the skeleton of the statement is visible.
Q2 · Can the formatted SQL be executed directly?
Yes — whitespace and line breaks have no semantic effect, so formatting only changes layout. Two caveats: when compressing multi-line to single-line, the contents of string literals are preserved verbatim and never touched; and dialect-specific syntax (stored procedures, some window-function branches) is supported to varying degrees by different formatters, so validate in the target database before running anything critical.
Q3 · Which SQL dialects are supported (MySQL, PostgreSQL, Oracle)?
The tool formats the common SQL skeleton — SELECT, FROM, WHERE, JOIN, GROUP BY and friends — which covers the base statements of all mainstream dialects. Dialect-private syntax (MySQL's LIMIT, Oracle's ROWNUM, vendor-specific JSON functions) is preserved as ordinary tokens, so formatting still works. Deeply dialect-dependent stored procedures are better served by an IDE plugin with full dialect support.
Q4 · Will SQL with sensitive table or column names be uploaded?
No. Parsing and formatting happen entirely in your browser; the statement never crosses the network and nothing is stored. As a general habit with any online tool, though, replace highly sensitive literals (phone numbers, keys) with placeholders before pasting production SQL.
Q5 · Does formatting actually help debug a slow query?
Enormously — step one of performance work is understanding what the query does. Once formatted, check clause by clause: does SELECT fetch columns you never use; are the JOIN order and conditions sound; does WHERE wrap a column in a function (a classic index-killer); how much data survives before GROUP BY. Format, review section by section, then confirm with EXPLAIN — that is the standard path for a long query.