SQL Formatter Online – Beautify & Format SQL Queries

A SQL formatter, often called a SQL beautifier or SQL query formatter, takes SQL that was minified, generated, or written on one line and lays it out with consistent indentation and line breaks. Formatting SQL online is useful when a query is hard to read in a log, a ticket, or a pull request.

Beautifying SQL changes how the text is arranged. It does not run the statement, connect to a database, or decide whether the query is fast. Minifying does the opposite visually: it collapses insignificant whitespace so a script is compact again.

This page formats SQL in your browser. There is no signup, and the query is not uploaded to EverydayTools for formatting. Dialect, indentation, and keyword case can be remembered on this device. The SQL text is not stored.

1. Paste or upload SQL. Paste your SQL query or upload a .sql file.
2. Choose dialect and style. Choose the SQL dialect and formatting preferences.
3. Format, then copy or download. Click Format SQL or press Ctrl/Cmd + Enter, review the output, then copy or download it.

SQL syntax varies between database systems, so selecting the matching dialect improves formatting for dialect-specific syntax. A MySQL SQL formatter needs to keep backtick identifiers. A PostgreSQL SQL formatter needs dollar quotes, :: casts, and $1 parameters. A SQL Server / T-SQL formatter needs bracketed names and @variables. The same idea applies to a SQLite SQL formatter, an Oracle PL/SQL formatter, a BigQuery SQL formatter, a Snowflake SQL formatter, and a Redshift SQL formatter.

• Standard SQL
• PostgreSQL
• MySQL
• MariaDB
• SQL Server / T-SQL
• SQLite
• Oracle / PL/SQL
• BigQuery
• Snowflake
• Redshift
• DuckDB
• ClickHouse
• Spark SQL
• Hive
• Trino / Presto
• Db2
• Db2 for i
• SingleStoreDB
• TiDB
• N1QL

Standard SQL is the right starting point for portable queries. If the formatter reports a token it does not recognize, switch to the dialect you actually run. The wrong dialect can misread quoting. PostgreSQL dollar quotes are not MySQL backticks, and the reverse is also true.

• SELECT queries

  Column lists, aliases, and DISTINCT wrap instead of staying on one line.

• INSERT statements

  Column lists and VALUES rows break onto indented lines.

• UPDATE statements

  SET assignments and the WHERE clause separate.

• DELETE statements

  The target table and filters stay readable.

• JOIN-heavy queries

  Each join and its ON condition gets its own indented block.

• CTEs

  Each WITH body indents independently of the final SELECT.

• Subqueries

  Nested SELECTs indent inside parentheses.

• CASE expressions

  WHEN, THEN, and ELSE stack under CASE.

• GROUP BY / HAVING

  Grouping keys and aggregate filters break onto their own lines.

• ORDER BY / LIMIT

  Sort keys stay attached to ORDER BY, including DESC.

• Multiple statements

  Semicolon-separated statements format together.

• Comments

  Line comments and block comments stay in the formatted output. Minify removes them.

• Parameterized SQL

  Placeholders such as ?, :name, $1, and @name are preserved when the selected dialect recognizes them.

This is not a stored-procedure editor. BEGIN/END blocks, DELIMITER changes, and some vendor extensions may format only partly or return an error. Table and column identifiers are not renamed. Identifier case stays as you wrote it.

Semicolon on its own line only moves a semicolon that is already in the query. It does not add one. BETWEEN … AND stays together, and words inside quotes are not treated as keywords.

These use Standard SQL, 2-space indentation, and uppercase keywords. Your selected dialect and options produce the output in the tool.

select * from users where active = 1;

SELECT
  *
FROM
  users
WHERE
  active = 1;

select u.id,u.name,count(o.id) as order_count from users u left join orders o on o.user_id=u.id where u.status='active' group by u.id,u.name having count(o.id) > 0 order by order_count desc limit 20;

SELECT
  u.id,
  u.name,
  count(o.id) AS order_count
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.status = 'active'
GROUP BY
  u.id,
  u.name
HAVING
  count(o.id) > 0
ORDER BY
  order_count DESC
LIMIT
  20;

WITH active_users AS ( SELECT id, email FROM users WHERE status = 'active' ) SELECT * FROM active_users WHERE email IS NOT NULL AND id IN (SELECT user_id FROM orders);

WITH
  active_users AS (
    SELECT
      id,
      email
    FROM
      users
    WHERE
      status = 'active'
  )
SELECT
  *
FROM
  active_users
WHERE
  email IS NOT NULL
  AND id IN (
    SELECT
      user_id
    FROM
      orders
  );

SELECT CASE WHEN total > 100 THEN 'high' ELSE 'normal' END AS tier FROM orders;

SELECT
  CASE
    WHEN total > 100 THEN 'high'
    ELSE 'normal'
  END AS tier
FROM
  orders;

The formatter tokenizes the SQL and recognizes clauses, lists, and nested expressions. It then reflows whitespace and line breaks, applies indentation, and optionally changes keyword, function, or data-type casing. String literals and comments stay intact while formatting. Identifiers are not rewritten just to match a style.

Formatting and beautifying are the readable layout. Minifying changes source whitespace and removes comments, and it should preserve query semantics when the removed whitespace was insignificant. None of these modes execute SQL, optimize a plan, or turn invalid SQL into valid SQL. If a token cannot be recognized, you get an error instead of a silently damaged query.

The engine is the open-source sql-formatter library running locally. It is a formatter, not a database parser and not a linter. Procedural code and unusual vendor syntax can fail even when the same text would run on a server.

The same task shows up as SQL formatter online, SQL beautifier, SQL query formatter, format SQL online, format SQL query, pretty print SQL, SQL pretty printer, beautify SQL, online SQL formatter, and free SQL formatter. Some searches add a dialect, such as a MySQL formatter or a PostgreSQL formatter, or describe the input: format minified SQL, format one-line SQL, or a SQL formatter with no signup. The practical need is usually to make a query readable, copy it, or download it without creating an account.

• Cleaning SQL copied from application logs or a slow-query log.
• Formatting SQL from ORM output so the joins and filters are visible.
• Making a query easier to review in a pull request.
• Preparing SQL for documentation, a ticket, or a migration file.
• Expanding a one-line or minified query before debugging it.
• Reading a nested CTE or a JOIN-heavy report query.
• Standardizing keyword case and indentation before sharing a script.

When you need to build a SELECT query visually, use the SQL Query Builder, then format the result here if you want different indentation. When the payload is JSON rather than SQL, use the JSON Formatter. When comparing two generated SQL or text versions, use Text Diff.

Choosing the wrong SQL dialect

Backticks, brackets, and dollar quotes are not interchangeable. A dialect mismatch is a common reason a formatter errors or splits a quote it should have kept.

Assuming formatting validates SQL

A clean layout does not mean the database will accept the statement. Run it in the database you care about.

Assuming formatting optimizes SQL

Indentation does not change the execution plan. Performance work still means reading the plan, indexes, and predicates.

Breaking SQL with naive text replacement

Replacing every keyword with a line break will also hit words that only look like keywords. A formatter has to know the structure.

Modifying text inside quoted strings

A value such as 'FROM is text' must survive formatting. If a tool rewrites that text, it is changing the query.

Removing comments unexpectedly during minification

Minify on this page removes comments on purpose. Format keeps them. Use Format when the comments still matter.

Assuming every formatter supports stored procedures and every vendor extension

Procedures, triggers, and engine-specific syntax are outside what a general formatter can promise. Review that output, or expect an error, before you trust it.

SQL formatting runs in the browser. SQL is not sent to EverydayTools servers for formatting. No database connection is used, and no signup is required. Copy and download also stay on your device.

The page can remember non-sensitive preferences such as the selected dialect, indentation, and keyword case in local storage. It does not save the query. You should still avoid exposing secrets on a shared or unlocked device, because the text is visible on screen while you work.

• SQL Query Builder to assemble a SELECT, then format it here.
• JSON Formatter when the messy payload is JSON.
• Code Minifier & Beautifier for JavaScript, HTML, and CSS in one place.
• Text Diff to compare two SQL or text versions.
• Developer Tools for the rest of the developer utilities.
• All Tools to browse the full catalog.