SQL Formatter and Beautifier

How to use it#

Paste your query into the box above.
Choose the dialect you are writing for, or type a name such as Postgres or T-SQL to find it.
Set keyword case and indentation to match your house style.
Copy the result or download it as a .sql file, or tick One line to flatten it back for a config file.

Why a query arrives unreadable#

SQL is usually generated rather than written. It comes out of an ORM log, a slow query report, a stack trace, or a BI tool, and every one of those emits a single line however long the query is. A join across five tables becomes six hundred characters with no line breaks in it. The placeholders a driver leaves in, such as ? or $1, stay where they are.

Formatting puts each clause on its own line and indents what belongs to it, which is the difference between reading a query and decoding one. Nothing about the query changes: the database sees exactly the same statement, because whitespace between tokens has no meaning in SQL.

Choosing the dialect#

The dialect matters more than you would expect. The formatter parses the query before it reformats it, and each dialect has its own keywords and syntax. MySQL has backticked names and REPLACE INTO, PostgreSQL has ILIKE and casting with double colons, SQL Server has TOP and square brackets around identifiers, Oracle has CONNECT BY, and BigQuery has EXCEPT in a select list.

The list covers Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle (PL/SQL), BigQuery, Snowflake, Redshift, DuckDB, Spark SQL, Trino, Hive, ClickHouse, and Db2. Amazon Athena runs on Trino, and Databricks SQL on Spark, so pick those for queries written there.

Choose the wrong dialect and one of two things happens. Usually the query still formats but a dialect specific keyword is treated as an ordinary identifier, so it does not get capitalised or put on its own line. Occasionally the parse fails outright. Standard SQL is the safe default when your query uses nothing exotic.

Keyword case is a real argument#

Upper case keywords are the old convention, and the reason is worth knowing: it predates syntax highlighting. When everything was one colour, capitals were the only way to tell SELECT from a column called select. Plenty of style guides still require it, and plenty of teams find it shouty now that every editor colours keywords for them.

Keep leaves whatever you typed alone, which is what you want when pasting into a codebase with its own settled style. None of the three changes what the query does.

Going back the other way#

One line flattens the formatted query back onto a single line, for when it has to live inside a YAML file, a JSON config, an environment variable, or a command line argument, where line breaks are a problem.

Joining the lines is not quite enough, because a comment that starts with two dashes runs to the end of its line. Put on one line, it would comment out everything after it. So each of those becomes a /* */ comment, which ends where it says it does. The same goes for # comments in MySQL, MariaDB, BigQuery, and ClickHouse, and // comments in Snowflake. The text is read with your dialect's quoting rules, so two dashes inside a string or a quoted name are left alone, and a string keeps its spacing exactly as written. Everything else is separated by single spaces.

Frequently asked questions#

Is my query uploaded anywhere?

No. The parsing and formatting happen in this tab. Nothing is sent to a server, which matters because a real query usually names your tables, your columns, and sometimes your customers.

Does the dialect matter?

Yes. The query is parsed before it is reformatted, and dialects differ in keywords and syntax. The wrong one usually just leaves a dialect specific keyword unformatted, and occasionally fails to parse. Standard SQL is a safe default for an ordinary query.

Does formatting change what my query does?

No. Whitespace between tokens has no meaning in SQL, so the database receives an identical statement. Keyword case does not change behaviour either, since SQL keywords are not case sensitive.

Why did my query fail to format?

The parser could not read it. The usual causes are the wrong dialect selected, a genuine syntax error, or a template tag such as {% if %} or {{id}}, which is not SQL and usually stops the parser, so put a real value in its place. Driver placeholders are fine: Standard SQL reads ?, $1, :name, and @name, and the other dialects read the styles they define, such as $1 in PostgreSQL and @name in SQL Server.

Are my comments and strings safe?

Yes. Comments are kept where they are, and the contents of a string literal are never touched, so a string containing the word select stays exactly as you wrote it. On one line, a comment that starts with two dashes is rewritten as a /* */ comment with the same words, so it cannot swallow the rest of the query.

Can I get the query back on one line?

Tick one line. That is for putting a query inside a YAML file, a JSON config, or a command line argument, where line breaks get in the way. Runs of whitespace become single spaces, and comments that start with two dashes become /* */ comments so the query still runs. The one thing it will not flatten is a line break inside a string, because that is part of the value.