SQL Formatter & Beautifier — 11 Dialects, Minify, Highlight
Format messy SQL into readable, consistently indented queries for PostgreSQL, MySQL, T-SQL, BigQuery and more. Runs in your browser.
Runs entirely in your browser. Your SQL is never sent to a server, so schema names and data in queries stay private. Browse all free tools.
Found a problem, or something that could be better? We read every message and we fix things quickly.
This free SQL formatter turns a query pasted from a log, an ORM or a one-line migration into readable SQL: one clause per line, consistent indentation, and keywords in the case you choose. Pick your database dialect so syntax such as PostgreSQL :: casts and $$ function bodies, MySQL backticks, T-SQL [brackets] and @variables, or BigQuery and Snowflake QUALIFY clauses is understood instead of mangled.
Formatting only changes whitespace and the case of keywords, data types and function names. String literals, quoted identifiers and comments are left exactly as written. The formatter needs to parse your SQL to lay it out, so templated SQL (dbt or Jinja {{ }} blocks) and some vendor-specific statements can fail; when that happens it tells you the line and column it stopped at. Minify does the reverse: one line, comments removed, optimizer hints such as /*+ INDEX(...) */ kept.
How to use
- Paste one or more SQL statements into the box. A sample query is loaded so you can see the result first.
- Choose the dialect your database uses. This matters most for quoting, parameters and vendor syntax.
- Set keyword case, indent and the number of blank lines between statements. The output updates as you change them.
- Switch to Minify if you need the query on a single line, for example inside a JSON config or a shell command.
- Copy the result or download it as a .sql file.
Frequently asked questions
Does formatting change what my SQL query does?
No. The formatter only changes whitespace and the letter case of keywords, data types and functions, which SQL databases treat case-insensitively. String values, quoted identifiers ("Column", `col`, [col]) and comments are copied unchanged, so the query returns the same results. Table and column names are not re-cased, with one exception: an unquoted name that is also a keyword in the chosen dialect (for example an alias called month) follows the keyword case. Unquoted names are case-insensitive in most databases, so this rarely matters, but MySQL table names can be case-sensitive on Linux; choose Preserve to leave your text exactly as written.
Which SQL dialect should I pick?
The one your database runs. Standard SQL works for simple SELECT, INSERT and UPDATE statements, but it does not know PostgreSQL :: casts and $1 parameters, MySQL backtick identifiers and # comments, T-SQL square brackets, @variables and TOP, Oracle PL/SQL blocks, or the QUALIFY clause in BigQuery and Snowflake. If formatting fails with a parse error, picking the right dialect is the first thing to try.
Why does the formatter say "Parse error"?
It reached a token it did not expect for the chosen dialect. Common causes are a dialect mismatch, an unclosed bracket or quote, template placeholders such as {{ ref("orders") }} from dbt, or procedural code the parser does not cover. The status line shows the line and column and the box underneath points at the character, which is usually enough to find the issue.
Should SQL keywords be uppercase?
It is a convention, not a rule. Uppercase keywords (SELECT, FROM, WHERE) make the structure stand out from table and column names and are the most common style in documentation and style guides. Many teams using dbt or modern editors with syntax highlighting prefer lowercase. Pick one and apply it everywhere; this tool can convert either way, or preserve what you wrote.
Is it safe to minify SQL?
Yes for the query itself: minifying collapses whitespace and removes -- and /* */ comments, and never touches the inside of strings. Optimizer hints (/*+ ... */) and MySQL version comments (/*! ... */) are kept because they change behaviour. The cost is readability, so minify only for transport (a JSON config, an environment variable, a log line) and keep the formatted version in your repository.
Is my SQL sent to a server?
No. The formatter library is downloaded to your browser and runs there. Table names, column names and any data in your WHERE clauses never leave your machine.
Dialect differences that break formatters
• Identifier quoting: standard SQL and PostgreSQL use "double quotes", MySQL and MariaDB use `backticks`, SQL Server uses [square brackets]. A formatter set to the wrong dialect can read a quoted name as a string or an operator.
• Parameters: PostgreSQL uses $1, $2; MySQL and SQLite use ?; SQL Server uses @name; Oracle uses :name. These are kept exactly as written.
• Casts and operators: PostgreSQL has value::type, the JSON operators -> and ->>, and ILIKE. BigQuery and Snowflake have QUALIFY for filtering window functions. Spark and Hive have LATERAL VIEW.
• Strings and bodies: PostgreSQL function bodies are often wrapped in $$ ... $$ (dollar quoting) and escape strings use E'...'. Everything inside is treated as one string and left alone.
• Comments: -- and /* */ work everywhere; # starts a comment only in MySQL and MariaDB. In T-SQL, #name is a temporary table.
A readable SQL style in five rules
Published SQL style guides differ on details such as leading or trailing commas, but most agree on a few layout rules, and this formatter applies them by default:
• One major clause per line: SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT.
• One selected column per line, so diffs show exactly which column changed.
• Conditions after AND or OR on their own lines inside WHERE and ON.
• Subqueries and CTE bodies indented one level deeper than their parent.
• A blank line between statements in a script, so each statement reads as a unit.
What a formatter cannot do is name things well. Use table aliases that mean something (orders o is fine, t1 is not) and give computed columns an explicit AS name.
Related free tools
- JSON Formatter — Pretty-print, minify and validate JSON, with parse errors located by line and column. In your browser, no upload.
- JSON to TypeScript — Paste a JSON sample and get TypeScript interfaces, a Zod schema, JSON Schema or types for Go, Python, Java, C#, Kotlin, Swift and Rust.
- YAML Validator — Validate YAML with the exact line and column of each error, and catch the mistakes parsers accept silently: yes/no booleans, tabs, duplicate keys.
- Regex Tester — Test a regular expression against sample text with live match highlighting, capture groups and replace preview. Free, in your browser.
- Diff Checker — Compare two versions of a text, code or JSON file and see exactly which lines, words and characters changed.