SQL Formatter
Format and highlight SQL queries across multiple dialects
Formatted SQL will appear here...
About this tool
The SQL Formatter beautifies raw SQL queries with consistent indentation, keyword casing, and clause alignment. Paste minified or hand-written SQL and get readable, properly indented output in seconds. Supports MySQL, PostgreSQL, SQLite, BigQuery, Trino, and standard SQL dialects.
When to use it
- →Formatting auto-generated SQL from ORMs before adding to code review
- →Cleaning up long queries copied from database logs or profilers
- →Standardizing keyword casing across a team's SQL codebase
- →Making complex JOINs and subqueries readable for debugging
Tips
- ◆Choose the correct dialect — MySQL uses backtick identifiers while PostgreSQL uses double quotes.
- ◆Uppercase keywords (SELECT, FROM, WHERE) are the SQL standard and improve readability.
- ◆After formatting, review for implicit joins (comma-separated FROM tables) and replace with explicit JOINs.
Frequently asked questions
Does SQL formatting change the meaning or behavior of my query?
No. SQL formatting only changes whitespace and keyword casing — it has no effect on query semantics or execution. The database parses and executes the formatted query identically to the original. Keyword case, indentation, and line breaks are all ignored by SQL parsers.
Why do I need to select the correct SQL dialect?
SQL dialects have syntax differences that affect parsing. MySQL uses backtick identifiers (SELECT `column`) while PostgreSQL and standard SQL use double quotes (SELECT "column"). BigQuery has its own syntax for arrays and structs. Selecting the wrong dialect may produce incorrect formatting or fail to parse dialect-specific syntax like window functions or CTEs.
What is keyword case normalization and why does it matter?
SQL keywords are case-insensitive — select, SELECT, and Select are identical to the parser. Normalization enforces a consistent convention: UPPERCASE is the traditional SQL style and distinguishes keywords from identifiers at a glance. lowercase is sometimes preferred in modern style guides. The formatter applies your chosen convention uniformly across the entire query.
Can the formatter handle stored procedures, triggers, and CTEs?
Yes for CTEs (WITH clauses) — most formatters handle these well. Stored procedures and triggers use procedural extensions (PL/pgSQL, T-SQL, PL/SQL) that vary significantly between databases and are harder to parse universally. Complex procedural code may format partially or not at all — focus formatting efforts on the SQL SELECT/INSERT/UPDATE/DELETE portions.