How to use SQL formatter
- Paste your SQL.
- Pick the dialect, keyword case and indent.
- Copy the formatted query; it updates as you type.
Readable SQL in one paste
Queries copied from logs, ORMs, BI tools and Slack threads usually arrive as one long line. This formatter puts each clause on its own line, indents column lists, joins and conditions, and makes keywords one consistent case, so you can see the shape of the query at a glance: what it selects, how tables are joined, which filters apply. It updates as you type, and nested subqueries and common table expressions are indented by level.
Formatting changes only whitespace, line breaks and the case of keywords, data types and functions. Table and column names, string values, comments and the order of everything are left exactly as written, so the formatted query does the same thing as the original.
Dialects
Pick the database you're writing for: PostgreSQL, MySQL, SQLite, SQL Server, BigQuery, Snowflake, or standard SQL. Each understands its own syntax, such as PostgreSQL's :: casts and dollar-quoted function bodies, MySQL's backtick names, SQL Server's square brackets and TOP, and BigQuery's project.dataset.table paths. If a query won't parse, the tool says roughly where and suggests checking the dialect.
Private by design
SQL often carries more than it seems: table and column names that reveal how a product works, customer emails in WHERE clauses, API keys in connection strings. Online formatters receive all of it. Here the formatter runs inside your browser, loaded from this site the first time you paste a query, and nothing is uploaded, logged or stored.
Team style
Choose upper-case keywords, the most common convention in style guides, lower case, or keep them as typed, and an indent of two or four spaces. Formatting queries before they go into code review or documentation keeps diffs small and makes them easier to read.
Common uses
Reading a slow query from a database log before tuning it, cleaning up SQL generated by an ORM or a BI tool to see what it really does, formatting a migration before it goes into a pull request, and pasting a readable query into documentation, a ticket or a message to a colleague.
Questions
- Is my query sent to a server?
- No. Queries often contain table names, customer data or credentials in connection strings, so formatting happens entirely in your browser and nothing is saved.
- Why choose a dialect?
- Databases differ in syntax: SQL Server uses square-bracket names and TOP, MySQL uses backticks, PostgreSQL has :: casts and dollar-quoted strings, BigQuery has backtick-quoted project paths. The right dialect makes those parse and format correctly.
- Does it change what the query does?
- No. Only whitespace, line breaks and the case of keywords change; names, values and the order of everything stay exactly as written.