SQL Formatter
Beautify or minify SQL for MySQL, PostgreSQL, SQL Server, Oracle, SQLite and BigQuery
Runs entirely in your browser. Nothing you type or upload is sent to us or stored.
Results are for general guidance. Please check anything important before relying on it. Terms of use
How to Use
- Paste your query into Your SQL, tap Open .sql file to load one from your device, or tap Sample to try a ready-made one. Several statements separated by
;are fine. - Pick the SQL dialect your database uses: MySQL, PostgreSQL, SQL Server (T-SQL), SQLite, Oracle (PL/SQL), BigQuery or standard SQL. The right dialect matters for quotes, brackets and special keywords.
- Choose Format / beautify, then set Keyword case (UPPER, lower or keep as typed) and the Indent. The formatted query appears on the right as you type.
- Choose Minify instead to remove comments and extra spaces and get a compact query for code, logs or config files.
- Tap Copy or Download .sql. If the query has a syntax error, a red message shows the line and column to check.
Why format SQL?
Queries copied from application logs, ORMs or old reports often arrive as one long line. Formatted SQL puts each clause (SELECT, FROM, WHERE, GROUP BY) on its own line and indents the columns and conditions under it. Now you can check joins and filters at a glance, and a Git diff shows exactly which condition changed.
This SQL formatter uses the open-source sql-formatter library and runs in your browser. Your queries, table names and data are never uploaded, which matters when the SQL has customer or production details in it.
Worked example
A one-line query from a log:
With the MySQL dialect, UPPER keyword case and a 2-space indent, it becomes:
c.city,
SUM(o.amount) AS total
FROM
orders o
JOIN customers c ON c.id = o.customer_id
WHERE
o.status <> 'cancelled'
GROUP BY
c.city
ORDER BY
total DESC
LIMIT
5;
Formatting only changes spaces, line breaks and the letter case of keywords, function names and data types. Table names, column names and everything inside quotes stay as you wrote them, so the query does exactly the same thing.
Why the dialect matters
Each database quotes names and limits rows differently. If you pick the wrong dialect, the formatter may not recognise a bracket or keyword and report an error.
| Database | Quoted name | First 10 rows |
|---|---|---|
| MySQL / MariaDB | `order date` | LIMIT 10 |
| PostgreSQL | "order date" | LIMIT 10 |
| SQL Server | [order date] | SELECT TOP 10 … |
| Oracle (12c and later) | "order date" | FETCH FIRST 10 ROWS ONLY |
| SQLite | "order date" (also accepts [ ] and ` `) | LIMIT 10 |
| BigQuery | `project.dataset.table` | LIMIT 10 |
How minify works
Minify reads the query one character at a time, so it knows when it's inside a string, a quoted name or a comment. It then:
- removes
-- lineand/* block */comments (and#comments in MySQL and BigQuery), - keeps optimizer hints such as
/*+ INDEX(e emp_idx) */and MySQL/*!50100 … */comments, because they change how the query runs, - turns every run of spaces and line breaks into a single space, and removes spaces next to commas, brackets and semicolons,
- never touches text inside
'strings', quoted names or PostgreSQL$$ … $$function bodies.
SQL Server GO batch separators and MySQL DELIMITER lines are kept on their own lines, since client tools need them there.
Tips
- UPPER-case keywords with lower-case names is the most common team style, and it makes clauses stand out.
- Most teams use 2 or 4 spaces. Pick one and stick to it everywhere so diffs stay small.
- Formatting doesn't check table or column names. A neatly formatted query can still fail if a column doesn't exist.
- Stored procedures with a lot of procedural code (PL/SQL blocks, T-SQL control flow) come out reasonably well but not perfectly. Look over the result before you commit it.