SQL Formatter
Format tangled SQL into a readable, indented layout, or minify it into a single line. Supports MySQL, PostgreSQL, and Standard SQL.
'...') and comments (--, /* */) are left as-is.
Even if a word like select appears in a string, it won't be mistaken for a keyword, uppercased, or cause a new line.Dialect differences โ MySQL: Backtick (
`ident`) identifiers, backslash escapes in strings.
PostgreSQL: Dollar-quoted strings ($$ ... $$), nested block comments.
Standard: Double-quoted and bracketed identifiers. This is for token boundary detection, not full syntax validation.
What is the SQL Formatter?
SQL queries from logs or ORMs are often a single, long line, making them hard to debug. This formatter clarifies complex queries by breaking them down. It adds newlines for major clauses like SELECT, FROM, WHERE, and JOIN, and indents subqueries for a clear hierarchy. WHERE conditions with AND/OR and CASE statements are also split onto separate lines to reveal the logic. Crucially, it's built on a proper tokenizer, not simple text replacement. This means it never alters the contents of string literals or comments, so a word like 'select' inside a string is safe. Your data is also safe: all formatting happens in your browser and is never sent to a server.
How to use
- Paste your query into the `SQL Input` field or drag and drop a .sql file.
- Select the `SQL Dialect` (`Standard`, `MySQL`, or `PostgreSQL`) to handle syntax differences.
- Customize the output style using the `Keywords` case, `Commas` position, and `Indent` options.
- Click `Format (Pretty)` to get an indented, readable query, or `Minify` to compress it to one line.
- Use `Copy` to grab the result for your editor or `Save` to download it as a .sql file.
SQL Formatter guide
How this tool is used in real work, and what to watch out for.
Why Poor Formatting Is a Maintenance Cost
A 200-character query mashed into one line isn't just hard to read *now*. The real cost comes six months later. You misplace the cursor three times trying to add one condition, and your reviewer has to re-read the whole thing because they can't tell what changed.
When a query is broken down by clause, a git diff shows "one condition added to the WHERE clause." For a single-line query, the same change shows up as "this entire line was replaced." This can be the difference between a code review being possible or not.
That's why formatting isn't a matter of taste. If you're committing SQL to a repository, it pays for the team to standardize on one configuration. This tool's settings for keyword case, comma style, and indentation are saved in your browser, so once you set them, you'll get consistent output every time.
Leading vs. Trailing Commas: The Real Arguments
It might look like a style preference, but there are practical reasons why some developers insist on leading commas. Unlike JavaScript, SQL treats a trailing comma (after the last item) as a syntax error.
-- Trailing comma: To add a column to the last line, you have to edit the previous line too.
SELECT
id,
name, -- Forgetting to add a comma here is a syntax error
email
FROM users
-- Leading comma: Just add the new line. It's also safe to comment out the last line.
SELECT
id
, name
, email
FROM users| After item (a,) | Before item (, a) | |
|---|---|---|
| Readability | Natural โ the default for most teams | Awkward until you're used to it |
| Adding/deleting columns | Requires editing the comma on the previous line | Just edit the line in question |
| Diff noise | Adding one column changes 2 lines | Changes 1 line |
| Commenting out the last line | Leaves a trailing comma, causing an error | Safe |
Why It's Crucial to Leave Strings and Comments Untouched
Many SQL formatters on the internet are built with simple regular expression replacements, like "replace `select` with `SELECT`" and "add a newline before `from`." This works fine for ordinary queries.
The problem arises when those keywords appear in your data. This tool works by splitting SQL into tokens and treating string literals and comments as single, indivisible units. This ensures that whatever content is inside them is preserved, character for character.
- WHERE memo NOT LIKE '%select from where%' โ A regex-based formatter might break the query by inserting newlines into the middle of this string.
- WHERE title = 'Order by ํ๋งค๋' โ It's common for non-English text, like product names or post titles, to contain English keywords.
- -- Do not add an order by here โ Uppercasing keywords inside comments just adds noise to code reviews.
- SELECT '3''4' โ The tool correctly identifies the boundaries of values escaped with doubled single quotes.
When Does Dialect Choice Matter?
The Standard, MySQL, and PostgreSQL choices aren't for syntax validation, but for correctly identifying token boundaries. Each dialect differs in what it considers an identifier quote versus a string literal. If your query doesn't use the features below, the "Standard" setting will work just fine.
| Dialect | What it affects | When to choose it |
|---|---|---|
| MySQL | Backtick identifiers, backslash escapes in strings | When using backticks or strings with backslash escapes. |
| PostgreSQL | Dollar-quoted strings ($$ โฆ $$), nested block comments | When the SQL contains function bodies (e.g., CREATE FUNCTION โฆ $$). |
| Standard | Double-quoted and bracketed identifiers | When the other two don't apply; SQL Server style. |
Limitations: This Is a Formatter, Not a Parser
Even SQL with syntax errors will be formatted on a token-by-token basis. This means a query that can't be executed might still come out looking pretty. However, the tool will display a warning if it detects broken token boundaries, like unclosed quotes or mismatched parentheses.
When pasting logs from an ORM, be mindful of placeholders. `?` and `$1` are left as-is, and queries logged with Python's `%s` will also be in their unfilled state. If you intend to run the query, you'll need to manually substitute the values from the log's parameter array.
The "Subquery Depth" statistic can be a good starting point for a review. If the depth is over 3 and mixed with `IN (SELECT โฆ)`, the query is worth a closer look. However, this tool has no knowledge of the execution plan, so for performance analysis, you must always use your database's `EXPLAIN`.
Frequently asked questions
Will it change text inside strings or comments?
No. The tool tokenizes the SQL and treats strings and comments as single, untouchable blocks. It will not re-case or add line breaks based on keywords found inside them.
What's the difference between the SQL dialects?
The dialect choice affects how the code is tokenized. `MySQL` recognizes backtick identifiers, `PostgreSQL` handles dollar-quoted strings, and `Standard` supports quoted identifiers. This is not for syntax validation.
What happens to comments when I click `Minify`?
By default, comments are removed. To keep them, enable the `Keep comments when minifying` option. Line comments (`--`) will then be followed by a newline to prevent errors.
Are the SQL queries I enter sent to your server?
No. The entire formatting process runs in your browser. Your queries, including any sensitive data like table names or values, never leave your computer.