SQL Formatter

Format and Beautify SQL Online

The Tools Kit’s free SQL Formatter turns a dense, single-line query into clean, indented SQL you can actually read. Paste a query copied from an application log, an ORM, or a minified script, choose your database dialect, and click Format SQL: keywords are uppercased, each main clause starts on its own line, and the columns and conditions under it are indented consistently.

It works as a SQL beautifier and pretty printer for Standard SQL, MySQL, MariaDB, PostgreSQL, SQLite, SQL Server (T-SQL) and Oracle (PL/SQL). Formatting happens entirely in your browser, so queries that mention internal table names or customer data are never uploaded anywhere.

How to Use the SQL Formatter

1. 1

   Choose the SQL dialect

   Pick Standard SQL, MySQL, PostgreSQL, SQLite, MariaDB, SQL Server (T-SQL) or Oracle (PL/SQL) so vendor-specific syntax is parsed correctly.

2. 2

   Paste your SQL

   Replace the sample query with your own: a single-line query from a log, ORM output, or several statements separated by semicolons.

3. 3

   Click Format SQL

   The query is reformatted with uppercase keywords, each main clause on its own line, and 2-space indentation.

4. 4

   Copy the result

   Use the Copy button above the Formatted SQL box to put the cleaned-up query on your clipboard.

There is no account to create and no limit on how many queries you format.

What the Formatted SQL Looks Like

Here is a typical one-line MySQL query of the kind an ORM or a slow-query log produces:

select u.id, count(o.id) as orders from users u left join orders o on o.user_id = u.id where u.active = 1 group by u.id having count(o.id) > 5 order by orders desc limit 10

After formatting with the MySQL dialect selected, it becomes:

SELECT
  u.id,
  count(o.id) AS orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.active = 1
GROUP BY
  u.id
HAVING
  count(o.id) > 5
ORDER BY
  orders DESC
LIMIT
  10

A few rules are worth knowing. Clause keywords such as SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY and LIMIT always sit on their own line, and everything that belongs to the clause is indented two spaces beneath it. JOINs stay inside the FROM block, AND and OR conditions each get a new line, and a nested subquery is indented one level deeper than the query around it. Keywords like AS, LEFT JOIN and DESC are uppercased, but function names such as count() and every table, column and alias keep exactly the case you typed. Spaces are added around operators, so a=1becomes a = 1.

If you paste several statements separated by semicolons, each is formatted in turn with a blank line between them, and both -- line comments and /* */ block comments are kept in place.

Choosing the Right SQL Dialect

A SQL formatter has to parse your query before it can lay it out, and every database engine adds its own syntax on top of standard SQL. Selecting the matching dialect is what lets those extensions through. A PostgreSQL cast such as price::int or a SQL Server name like [Order Details] will fail to parse under Standard SQL, but formats cleanly once PostgreSQL or SQL Server (T-SQL) is chosen.

Formatting Is Not Validation

Beautifying SQL only changes whitespace, line breaks and keyword capitalization, so the formatted query does exactly what the original did. It also means the formatter is not a SQL validator. If the text cannot be parsed, for example because of an unclosed quote or syntax from a different dialect, you will see “Could not format this SQL. Check for a syntax issue.” If it can be parsed, it is formatted even when a table or column does not exist, because the tool never connects to a database or reads your schema. Always test the query against your own database before running it in production.

The output style is fixed: keywords are always uppercase and indentation is always two spaces. If your team’s style guide differs, use the result as a clean starting point and adjust it in your editor.

Common uses

• Making a long query from an application or slow-query log readable while debugging, often alongside the API payload you are inspecting in the JSON formatter.
• Reading the SQL an ORM or query builder generates, so you can spot a missing WHERE condition or an unexpected JOIN.
• Cleaning up queries before pasting them into a pull request, wiki page or ticket, the same way you might tidy markup and scripts with the code beautifier or an XML formatter.
• Preparing data work: format the query that exports a table, then reshape its output with the CSV to JSON converter or turn an API response into spreadsheet rows with JSON to CSV.
• Building and checking a pattern for a LIKE or REGEXP condition in the regex tester before dropping it into a formatted query.
• Documenting a full request flow, where a cURL converter turns the API call into code and this tool tidies the SQL behind it.

For more utilities like these, browse all of the developer tools on The Tools Kit.

SQL formatting terms explained

Frequently Asked Questions