SQL Formatter
Format SQL queries for readability. Supports 12 SQL dialects (PostgreSQL, MySQL, SQLite, SQL Server, BigQuery, Snowflake, and more) with configurable keyword casing and indentation.
Paste SQL above — formatted output appears here.About SQL Formatter
SQL grows fast — a five-line SELECT becomes a 200-line report query with joins, CTEs, window functions, and subqueries in production. Unformatted SQL is hard to read, hard to review, and hard to debug. This SQL Formatter beautifies queries for 12 major dialects: standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, T-SQL (SQL Server), Oracle PL/SQL, BigQuery, Snowflake, Redshift, Spark SQL, and DB2. Each dialect has its own reserved-word list and syntax quirks — picking the right one matters for dialect-specific keywords like BigQuery's ARRAY_AGG or PostgreSQL's ILIKE.
Options include keyword casing (UPPERCASE is the industry standard, lowercase is common in modern shops, or preserve the input's own casing) and configurable tab width (2 spaces is common, 4 is legacy). The formatter never changes query semantics — only whitespace, line breaks, and casing. Useful for cleaning up autogenerated SQL from ORMs, formatting ad-hoc queries before pasting into a code review, teaching junior developers what well-formatted SQL looks like, and comparing two structurally-similar queries after normalizing their layout. Runs entirely client-side using the sql-formatter library, so paste production queries and schemas freely — nothing leaves your browser.
How to Use
Paste your SQL query into the input box — a SELECT, INSERT, UPDATE, DELETE, or any DDL statement.
Pick the dialect matching your database. Dialect-specific keywords and functions format correctly.
Choose keyword case (UPPERCASE is the industry standard for readability).
Set tab width — 2 spaces is common; 4 for legacy code.
The formatted output appears instantly. Copy and paste back into your codebase or SQL client.
Frequently Asked Questions
Which SQL dialect should I pick?
Match it to your database. PostgreSQL for Postgres/Supabase/Neon. MySQL for MySQL/MariaDB (though MariaDB has its own option for tighter parsing). SQLite for local SQLite databases. T-SQL for SQL Server / Azure SQL. BigQuery and Snowflake for their respective cloud data warehouses. Standard SQL if you are unsure or writing portable SQL.
Does the formatter change my query logic?
No — the formatter only changes whitespace, indentation, line breaks, and (optionally) keyword casing. The parsed query is functionally identical to the input. Run EXPLAIN before and after to verify if you are cautious.
Why does my query fail to format?
Usually a syntax error in the input SQL — mismatched parentheses, missing quotes, or a truly unrecognized keyword. The error message will point you at the position. If the SQL is valid and still fails, try switching to Standard SQL dialect — it's the most lenient parser.
Should database keywords be UPPERCASE?
By convention yes — UPPERCASE keywords contrast with lowercase table and column names, making SQL faster to scan. Most style guides (SQLBolt, Simon Holywell's SQL Style Guide, Mode Analytics) recommend it. Some modern shops prefer lowercase-everywhere for consistency with code — either is fine, but pick one and be consistent.
Is my SQL sent to a server?
No. The sql-formatter library runs entirely in your browser. Paste production queries, sensitive schema references, real customer IDs — nothing is uploaded. Verify by opening the network tab and formatting a query: zero outbound traffic.