SQL Formatter
Beautify or minify SQL for MySQL, PostgreSQL, T-SQL and more. Runs in your browser.
About this sql formatter
This SQL formatter turns a dense, one-line query into clean, indented SQL you can read and review. It supports 20 dialects, including MySQL, PostgreSQL, SQL Server, Oracle, SQLite and BigQuery, and it can also minify a query to a single line.
Paste a query from a log, an ORM debug print or a BI tool. Pick your database, then choose keyword case, indent and a few layout rules. The output updates as you type, so you can try a setting and see the effect right away.
Formatting happens in your browser. Your queries, table names and any values inside them are never sent to a server or saved behind a link.
Features
20 SQL dialects
Standard SQL, MySQL, MariaDB, PostgreSQL, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, ClickHouse, Db2, Db2 for i, Hive, Spark, Trino, TiDB, SingleStoreDB and Couchbase N1QL.
Case control in three places
Set keywords, data types and function names separately to UPPER, lower, or as typed. Many teams want SELECT in capitals but count() in lowercase, and this handles that.
Layout options teams argue about
Put AND and OR at the start or end of a line, choose a tabular layout that lines keywords up in a column, set how wide an expression may get before it wraps, and decide where semicolons go.
Safe one-line minify
Minify squeezes a script onto one line without touching strings, quoted names, PostgreSQL $$ bodies or optimizer hints. T-SQL GO separators stay on their own lines so the script still runs.
Readable errors
When a query cannot be parsed, you get a short message with the line and column and a button that jumps there. No wall of parser output.
Big files and quick stats
Open a .sql file from your device. The tool counts statements and shows lines and size before and after. Files over about 200 KB format when you press the button, so typing stays smooth.
How to use the sql formatter
- 1Paste a query or open a .sql file.
- 2Pick your database dialect, keyword case and indent, or switch to Minify.
- 3Copy the result or download it as a .sql file.
When to use it
Debugging ORM output
Frameworks often log the generated SQL as one long line. Format it to see the joins and the WHERE clause and spot the missing condition.
Code review
Format a migration or a report query in the team style before opening a pull request, so the diff shows real changes instead of whitespace.
Putting a query in a config file or a log search
Minify a multi-line query to one line for a YAML value, an environment variable or a search box that does not accept line breaks.
Learning SQL
Paste a long example from a tutorial and format it. Each clause on its own line makes the order of SELECT, FROM, WHERE, GROUP BY and ORDER BY easy to follow.
Which SQL dialect should I choose?
Choose the database the query will run on. Standard SQL follows the ISO/IEC 9075 standard and covers what most engines share, so it works for simple queries. Vendor features need the right dialect. SQL Server wraps names in [square brackets], MySQL uses `backticks` and # comments, and PostgreSQL has $$ quoted function bodies and the :: cast operator.
If you see a parse error on a query that runs fine in your database, the dialect is the first thing to check. Formatting never translates one dialect into another. It only changes layout and letter case.
Should SQL keywords be uppercase?
SQL keywords are not case sensitive, so SELECT and select run the same. Uppercase is the most common convention because it separates keywords from table and column names at a glance. Lowercase is popular in teams that format SQL like regular code. Pick one and use it everywhere. Consistency matters more than the choice.
Be careful with identifiers. In PostgreSQL, unquoted names fold to lowercase while "Quoted" names keep their case, so changing the case of a quoted identifier can break a query. That is why this tool changes keywords, data types and functions, but never your table or column names.
What does minifying SQL do, and when is it safe?
Minify removes line breaks, extra spaces and, by default, comments. The query does exactly the same thing. A few details make it safe:
- Text inside quotes is copied byte for byte, so 'two spaces' keeps both spaces.
- A -- comment would swallow the rest of a one-line query, so it is removed or rewritten as /* comment */ when you keep comments.
- Optimizer hints like /*+ INDEX(t) */ and MySQL /*! ... */ comments change how the query runs, so they are always kept.
- GO is a batch separator for SQL Server tools, not a SQL statement. It stays on its own line.
Why use Mavros
| Mavros | Typical upload sites | |
|---|---|---|
| Where your SQL goes | Stays in your browser | Sent to a server, sometimes saved behind a share link |
| Dialects | 20, from MySQL to ClickHouse | Often 3 to 5, or none |
| Case options | Keywords, data types and functions set separately | Keywords only |
| Parse errors | Short message, line, column and Go to error | Raw parser output or nothing |
| Minify | Keeps strings, hints, $$ bodies and GO lines intact | Simple whitespace removal |
| Sign-up or ads in the way | None | Common |
Tips
- Match the indent to your editor settings: 2 or 4 spaces, or tabs. Mixed indentation makes every later diff noisy.
- Try the tabular layout for long SELECT lists. Lining up keywords in one column makes wide reports easier to scan.
- Use the text diff tool after formatting two versions of a query to see what really changed.
- Need to rename a column across a long script? Format it first, then use find and replace so every occurrence sits on a clear line.
- If your query results come back as JSON, the JSON formatter makes them readable, and the HTML, CSS and JS minifier handles front-end files.
Questions
Does formatting change what my query does?
No. Formatting only changes whitespace, line breaks and the case of keywords, data types and functions. Table names, column names, values and the order of clauses stay exactly the same.
Why do I get a parse error on a query that works?
Usually the dialect is wrong. Vendor syntax such as SQL Server [brackets] or PostgreSQL :: casts may not parse under another dialect. If the dialect is right, look for a missing quote or bracket near the reported line and column.
Which databases are supported?
Twenty dialects: Standard SQL, MySQL, MariaDB, PostgreSQL, SQLite, SQL Server, Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, ClickHouse, Db2, Db2 for i, Hive, Spark, Trino, TiDB, SingleStoreDB and N1QL.
Can I keep comments when I minify?
Yes. Turn on Keep comments. Line comments that start with -- or # are rewritten as /* ... */ so they cannot hide the rest of the one-line query. Optimizer hints are kept either way.
Can it format stored procedures and multiple statements?
Yes for multiple statements. Paste a whole script, and each statement is formatted with the number of blank lines you choose between them. Procedural code such as stored procedures is formatted on a best-effort basis, so pick the matching dialect and check the result.
Uppercase or lowercase keywords: which is correct?
Both are correct, because SQL keywords are not case sensitive. Uppercase is the most common style. What matters is using one style across a codebase so queries look the same everywhere.
Does it check whether my SQL is valid?
Only partly. It catches syntax errors like an unclosed bracket or quote, but it does not know your tables. A query can format cleanly and still fail because a column name is wrong.
Is my SQL uploaded or stored?
No. The formatter runs in your browser. Queries, table names and values are never sent to a server, and nothing is saved behind a public link.