Answer: The SQL Formatter produces your output instantly from the input you provide — everything runs in your browser, free, with no signup required.
Format and beautify SQL queries online. Free SQL formatter with keyword capitalization and proper indentation.
SQL that runs is not the same as SQL that reads. Over months of edits, queries accumulate inconsistent capitalization, tangled join conditions, and subqueries squeezed onto a single line. A formatter — also called a beautifier or pretty-printer — applies a consistent layout to the text without changing what the query does, because it only inserts whitespace where whitespace is meaningless to the parser. The result is code that survives review, diffs cleanly in version control, and can be handed to a colleague without a walkthrough.
This tool formats SQL in the browser using a syntax-aware engine, not naive keyword replacement. That means it understands string literals, quoted identifiers, and comments well enough to leave their contents untouched, reflows SELECT lists, ON clauses, and CASE blocks onto predictable lines, and normalizes keyword casing to your chosen convention — uppercase, lowercase, or capitalized. Nothing is sent to a server; the formatting happens locally in your browser.
Formatted output is a starting point, not a style verdict. Teams that adopt one layout convention — and enforce it with a formatter in the editor or CI — spend less time arguing about indentation and more time reading the logic, which is the entire point.
The engine performs a fixed set of transformations. It inserts line breaks before major clauses such as FROM, WHERE, GROUP BY, and ORDER BY; indents join conditions under their JOIN keyword; breaks long column lists onto one column per line; aligns CASE WHEN branches; and standardizes keyword case. It does not rename aliases, add missing keywords, remove dead columns, or otherwise alter the query semantics — a formatter is deliberately not an optimizer or a linter.
Preservation rules matter more than the changes. Text inside single-quoted string literals is left exactly as written, because 'USA' and 'usa' are different data values in most collations. Contents of comments, both line comments with double dashes and block comments, survive untouched. Identifier casing is left alone by default since many databases on Linux fold unquoted identifiers to lowercase while preserving quoted ones.
There is no ANSI or ISO standard for SQL layout — only widely followed conventions. The table below summarizes the main options teams pick between. Any of them works; the professional norm is to pick one and apply it uniformly.
Keyword casing is the most visible choice. Uppercase keywords (SELECT ... FROM) descend from an era of scarce syntax highlighting and remain the most common convention in published documentation. Lowercase reads more like modern application code. Indent style — tabs versus a fixed two-space indent — is usually inherited from the surrounding language team: two or four spaces dominate, and the formatter supports both.
| Convention | Example | Where you see it |
|---|---|---|
| Uppercase keywords | SELECT id FROM users; | Vendor docs, DBA scripts, textbooks |
| Lowercase keywords | select id from users; | Application codebases, ORM-adjacent SQL |
| Leading comma lists | …id , name | Teams that comment out columns often |
| Trailing comma lists | id, name | Most SQL style guides |
| 2-space indent | joins indented two spaces | Matches common app-code style |
The strongest argument for automated formatting is diff hygiene. When everyone's SELECT list lines up the same way, a code review shows only the columns that actually changed instead of a wall of re-indented text. Most database IDEs can format on save, and formatters are available as CLI tools that can run in CI to reject unformatted SQL, the same way linters treat code. Paste, format, commit — the habit takes a week to form and pays off indefinitely.
A few practical notes make formatting sessions smoother. Very large statements — long INSERT value lists or wide reporting queries with dozens of columns — are handled fine, but browsers do have practical text limits, so for multi-megabyte dump files a command-line formatter is the better tool. Pasting from spreadsheets or word processors can carry smart quotes that SQL does not recognize; if a formatted query suddenly errors, non-breaking spaces and curly quotes are the first suspects. And if a fragment is incomplete — a missing closing parenthesis, an unterminated string — the formatter will show it plainly, which makes it a quick syntax sanity check before a query ever reaches the database driver.
Does formatting change what my query does?
No. A SQL formatter only inserts and normalize whitespace, which the SQL parser ignores outside string literals and comments. Execution plans, results, and semantics are identical before and after.
What SQL dialects does the formatter support?
It handles the common core — SELECT/INSERT/UPDATE/DELETE, JOINs, CTEs (WITH clauses), window functions, and CASE expressions — shared by MySQL, PostgreSQL, SQL Server, SQLite, and Oracle. Dialect-specific extensions are formatted reasonably but may not be recognized as keywords.
Why do keywords get uppercased?
Uppercase keywords visually separate the query structure from table and column names. It is purely convention — SQL is case-insensitive for keywords in virtually every dialect — and the formatter lets you choose lowercase or capitalized instead.
Will it reformat text inside strings or comments?
No. A syntax-aware formatter preserves string literals, quoted identifiers, and comment contents exactly as written, since changing them could alter data comparisons or documentation.
Is my SQL uploaded anywhere?
No. Formatting runs entirely in your browser with JavaScript, so the query never leaves your machine — suitable for proprietary or sensitive schema and data references.