What a SQL formatter does
SQL is forgiving about layout — a query runs the same whether it's one long line or carefully indented. That freedom is exactly why hand-written and machine-generated queries drift into an unreadable mess. A formatter parses the query and re-emits it with consistent indentation, line breaks, and keyword casing, without changing a single token of meaning.
Dialects matter. PostgreSQL, MySQL, T-SQL, Oracle PL/SQL, and BigQuery differ in how they quote identifiers, name functions, and mark parameters, so formatting against the right dialect keeps those details intact. Picking your engine here means clauses like JOIN, GROUP BY, and window functions land where you expect.
It all runs locally in your browser — the query text is never uploaded — so it's safe to paste production queries, proprietary schemas, and anything with real table names in it.
Format vs. Compact
Indented, line-broken, and keyword-cased so each clause is easy to read and review.
Collapsed to a single line for embedding in code, configs, or a log entry.
Where developers use it
Reviewing a pull request
Reformat a teammate's dense query so the joins and filters are legible before you approve the migration.
Untangling generated SQL
Paste the single-line query an ORM logged and format it to see exactly what hit the database.
Cleaning up a migration
Standardize casing and indentation across a schema change so the diff stays readable in version control.
Frequently asked questions
It formats Standard SQL plus the dialect-specific syntax of PostgreSQL, MySQL, MariaDB, SQLite, BigQuery, Oracle PL/SQL, and T-SQL (SQL Server). Pick the matching dialect so quoting, functions, and parameter placeholders are handled correctly.
Nested subqueries and WITH clauses (CTEs) are parsed and indented to reflect their nesting depth, so each level lines up beneath its parent. The structure becomes visible at a glance — the logic and execution order are unchanged.
No. Formatting only rearranges whitespace and line breaks and adjusts keyword casing — the tokens, identifiers, and string literals are untouched, so the query is logically identical. It's purely about readability.
No. Both line comments (-- …) and block comments (/* … */) are preserved and repositioned with the statements they annotate, so documentation in your query survives formatting.
SQL keywords are case-insensitive, so it's purely a style choice. Uppercasing SELECT, FROM, and WHERE makes the structure scannable against lowercase table and column names — a long-standing convention. Use the UPPER / lower / Aa control to match your team's style guide.
No. Parsing and formatting run entirely in your browser, so schema names, table structures, and query logic stay on your machine — safe for production queries and proprietary schemas.