🗃️ SQL Formatter

Beautify and format SQL queries — MySQL, PostgreSQL, Oracle, Databricks and more.

DIALECT:

INDENT

KEYWORDS

DATA TYPES

QUICK LOAD:

INPUT SQL

FORMATTED OUTPUT

🗃️

Paste SQL on the left to see formatted output

Auto-formats as you type · 100% private

About SQL Formatter

SQL written in a hurry or generated by ORMs, query builders, or logging pipelines is often a single unreadable line or an inconsistently indented mess. This free online SQL formatter beautifies and standardises SQL queries across 8 major dialects — MySQL, PostgreSQL, Databricks, Oracle, SQL Server, BigQuery, Snowflake, and SQLite — all entirely in your browser with zero data sent to any server.

The formatter preserves your query's logic while applying consistent indentation, configurable keyword casing (UPPERCASE, lowercase, or Preserve), optional AND/OR placement at line beginnings, and proper alignment of SELECT columns, JOIN conditions, and WHERE clauses. It is especially useful when reading query plans, reviewing ORM-generated SQL, or preparing queries for documentation and pull request reviews.

How to format SQL

Paste your SQL query into the left panel.
Select the dialect that matches your database (MySQL, PostgreSQL, Databricks, etc.).
Choose your preferred indent size (2 spaces, 4 spaces, or Tab) and keyword case (UPPER, lower, or Preserve).
The formatted output appears instantly in the right panel with syntax highlighting.
Click ⎘ Copy to copy the formatted query, or ⬇ Download to save it as a .sql file.

Supported SQL dialects

🐬 MySQL & MariaDB

Full MySQL 8 syntax including window functions, CTEs, JSON functions, generated columns, and MariaDB-specific extensions.

🐘 PostgreSQL

Dollar-quoted strings, RETURNING, ON CONFLICT (upsert), LATERAL joins, and advanced window functions.

⚡ Databricks / Spark

Delta Lake syntax: CREATE OR REPLACE TABLE, USING DELTA, ZORDER BY, OPTIMIZE, LIQUID CLUSTERING, and Spark SQL functions.

🔶 Oracle PL/SQL

ROWNUM, CONNECT BY hierarchical queries, MERGE, DUAL, NVL, DECODE, and Oracle-specific date functions.

🪟 SQL Server T-SQL

TOP N, NOLOCK hints, CROSS APPLY, OUTER APPLY, FOR XML, FOR JSON, and T-SQL procedural constructs.

☁️ BigQuery

STRUCT and ARRAY types, UNNEST, QUALIFY, PARTITION BY date, and Google BigQuery date/time functions.

❄️ Snowflake

VARIANT, OBJECT_CONSTRUCT, ARRAY_AGG, QUALIFY, COPY INTO, FLATTEN, and Snowflake semi-structured data functions.

🎛️ Format options

Indent size (2/4 spaces or Tab), keyword case (UPPER/lower/Preserve), data type case, AND/OR at line start, and comma placement.

Frequently Asked Questions

Why should I format SQL before sharing it?

Formatted SQL is significantly easier to review, debug, and maintain. Consistent indentation makes JOIN conditions, subqueries, and WHERE clause logic immediately apparent. When opening a pull request that includes SQL changes, well-formatted queries reduce review time and catch logic errors that are invisible in minified form.

Does the formatter change the meaning of my query?

No — the formatter only changes whitespace, line breaks, and keyword casing. It never reorders clauses, modifies column order, or alters the logic of your query. The formatted output is semantically identical to the input.

Which dialect should I choose if I'm not sure?

For most standard SQL (SELECT, INSERT, UPDATE, DELETE, JOIN), any dialect will format correctly. The dialect setting mainly affects how dialect-specific keywords and functions are highlighted and normalised. Start with PostgreSQL or MySQL and switch if the formatter misinterprets a specific construct.

Can I format stored procedures and PL/SQL blocks?

Yes, for Oracle PL/SQL and SQL Server T-SQL, the formatter handles procedural blocks including BEGIN/END, DECLARE, IF/ELSE, LOOP, CURSOR, and EXCEPTION blocks. Select the matching dialect for best results.

Is my SQL data safe in this tool?

Completely. The formatter runs entirely in your browser using JavaScript. No SQL is ever transmitted to a server, logged, or stored. You can safely paste production queries, credentials in connection strings, or sensitive schema definitions.

SQL formatter guide: clean and standardise queries across dialects

SQL queries accumulate technical debt quickly. A query that was clear when it was written becomes hard to read after a few rounds of edits, copy-paste from Stack Overflow, copy-paste from a BI tool, or automatic generation by an ORM. Long single-line queries with no indentation are particularly difficult to review, optimise, or hand over to another developer.

Braxik's SQL formatter takes a raw SQL query — however messy — and reformats it with consistent keyword casing, aligned clauses, and indented subqueries. The goal is to make the structure of the query visible: which tables are joined, on what conditions, which columns are selected, and how filters and groupings are applied.

The formatter supports multiple SQL dialects: PostgreSQL, MySQL, MariaDB, SQLite, Oracle, Microsoft SQL Server, BigQuery, Snowflake, Databricks, and ANSI SQL. Dialect selection matters because keywords, quoting styles (backticks vs double quotes), and built-in function names differ between databases. Choosing the closest dialect produces more accurate formatting.

You can also use the formatter in minify mode to collapse a formatted query onto a single line. This is useful for storing queries in configuration files, logging them compactly, or embedding them in code strings where multi-line SQL is inconvenient.

How it works

The formatter tokenises the SQL input into keywords, identifiers, operators, literals, and whitespace. It then applies dialect-specific rules to determine how tokens should be grouped, capitalised, and indented. Major clause keywords (SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, JOIN) start on new lines. Subqueries and CTEs are indented relative to their parent query.

Keyword casing is applied based on the selected style — UPPERCASE is the most common and improves the visual separation between SQL keywords and developer-written identifiers. Identifier quoting follows the dialect rules: backticks for MySQL, double quotes for PostgreSQL and ANSI SQL.

The formatter does not execute the query or connect to a database. It works on syntax only and cannot validate that tables, columns, or functions actually exist in your schema.

Common uses

Clean up a complex multi-join query before code review or including it in a pull request description.
Reformat auto-generated SQL from Hibernate, JPA, JOOQ, or a BI tool into something a human can review.
Format a Databricks or BigQuery query before adding it to a data pipeline or dbt model.
Minify SQL for compact storage in YAML configuration, environment variables, or application properties files.
Normalise a query received from a vendor or external system before running EXPLAIN ANALYZE on it.
Format stored procedure or function bodies before committing them to version control.
Reformat a Stack Overflow example query into your team's preferred style before adapting it to your schema.

Before you rely on the result

Formatting changes only whitespace and casing — it should not change query semantics. However, always review the formatted output before running any write operations (UPDATE, DELETE, INSERT, TRUNCATE, DROP).
SQL formatting cannot detect logic errors, missing indexes, or incorrect join conditions. Use EXPLAIN or your database's query analyser for performance and correctness analysis.
Comments that explain business logic, filter conditions, or unusual joins should be preserved — check that they remain correctly associated with the relevant code after formatting.
For dialect-specific syntax like window functions, CTEs, or JSON operators, confirm that the selected dialect produces output your database understands.
When formatting queries with dynamic parameters (? placeholders or :named parameters), verify that parameter positions are unchanged after formatting.
Minified SQL for production use should be reviewed for readability in logs and error messages — extremely long single-line queries are difficult to debug in production.
If your query uses proprietary functions or syntax that is not in the selected dialect, the formatter may handle them inconsistently — review those sections manually.