SQL Formatter and Beautifier

About this tool

A SQL query that arrives as one long line, from a log file, an ORM debug print or a colleague's chat message, is hard to read and harder to review. This SQL formatter rewrites the layout of a query so that each clause starts on its own line and the columns, joins and conditions under it are indented consistently. It uses the open-source sql-formatter library (version 15.4.0) and runs entirely in your browser, so nothing you paste is sent to a server.

How to use the SQL formatter

1. Pick the dialect your database uses. Standard SQL works for simple queries, but a specific dialect understands that database's quoting rules, operators and keywords.
2. Choose an indent of 2 spaces, 4 spaces or a tab.
3. Choose the keyword case. UPPERCASE writes SELECT, FROM and WHERE in capitals, lowercase does the opposite, and Keep as typed leaves keywords alone.
4. Paste your SQL and click Format SQL. Changing any option formats the query again straight away.
5. Copy the result or download it as a .sql file. If the formatter cannot read the query, the status line shows the line and column it stopped at and the output box points to that spot.

Why formatting matters for code review and diffs

Version control tools compare files line by line. If a whole query sits on one line, changing a single condition marks the entire line as changed and a reviewer has to hunt for the difference. With one column or condition per line, the same edit shows up as one changed line. Consistent formatting also stops "noise" diffs, where two people's editors indent the same query differently. Formatting every query the same way before committing it keeps the history readable. To see the effect, paste the before and after versions into the Text Diff tool.

What the formatter changes, and what it leaves alone

The formatter changes whitespace (line breaks, indentation and spacing around commas and operators) and, if you ask it to, the letter case of keywords. It does not rename tables, reorder columns, rewrite joins or change values. In testing with this tool:

• String literals are untouched. 'select from' stays exactly as typed, even with UPPERCASE keywords selected.
• Comments are kept. Both -- line and /* block */ comments survive, with their text unchanged.
• Quoted identifiers are untouched. "Select" in PostgreSQL, `Select` in MySQL and [where] in T-SQL keep their case.
• Function names keep their case. Keyword case does not apply to count() or sum().

Two behaviours are worth knowing about. First, keyword case applies to every word the chosen dialect treats as a keyword, even when that word is an unquoted column name. With the Standard SQL dialect, a column called user or value becomes USER or VALUE in UPPERCASE mode. Most databases treat unquoted names as case-insensitive, so this rarely matters, but pick Keep as typed if exact case is important to you. Second, a function the dialect does not recognise, such as your own my_func(x), can come out as my_func (x) with a space. Most databases accept that, but the MySQL manual says some built-in functions, COUNT among them, must have no space before the parenthesis unless the IGNORE_SPACE mode is on. Choosing the correct dialect reduces both effects.

Dialect differences in brief

The biggest practical difference between dialects is how a name is quoted when it clashes with a keyword or contains spaces:

Sources: the PostgreSQL lexical structure page, the MySQL schema object names page, and Microsoft's database identifiers page. Dialect-specific syntax can stop the Standard SQL setting from reading a query: in testing, a T-SQL bracket such as [a] or a PostgreSQL cast such as a::int gave a parse error until the matching dialect was chosen.

Worked example

The sample in the tool is a single-line report query with a comment above it. Formatted with the default settings (Standard SQL, 2-space indent, UPPERCASE keywords), it becomes:

-- Top customers by 2026 revenue
SELECT
  c.id,
  c.name,
  count(o.id) AS orders,
  sum(o.total) AS revenue
FROM
  customers c
  JOIN orders o ON o.customer_id = c.id
WHERE
  o.status = 'paid'
  AND o.created_at >= '2026-01-01'
GROUP BY
  c.id,
  c.name
HAVING
  sum(o.total) > 1000
ORDER BY
  revenue DESC
LIMIT
  10;

Each clause keyword sits on its own line, every selected column and grouping column has its own line, and the second WHERE condition starts with AND so it can be commented out or deleted cleanly. The strings 'paid' and '2026-01-01', the comment and the function names count and sum are unchanged.

This tool formats SQL; it does not validate it

The formatter reads the query's structure well enough to lay it out, and it reports text it cannot parse, such as an unclosed quote or an unbalanced bracket. It is not connected to a database, so it cannot tell you whether a table or column exists, whether types match, or whether the query will run. A query can format perfectly and still fail. Run it against a development database to be sure.

Common mistakes

• Using the wrong dialect. A parse error on a bracketed name or an operator such as :: often means the query belongs to a different dialect.
• Formatting a template, not SQL. Placeholders from templating languages, such as {{ table }}, are not SQL and may cause parse errors.
• Expecting optimisation. Layout has no effect on how fast a query runs. The database's query planner works from the parsed statement, not its whitespace.

Use cases

Developers use a SQL formatter to tidy queries copied from application logs, to prepare SQL for a pull request, to make a long stored query readable before debugging it, and to paste clean examples into documentation. Data analysts use it to clean up generated queries from BI tools. If you work with other formats too, the JSON Formatter does the same job for JSON, and YAML to JSON converts configuration files.