SQL Formatter

The exact 11 keywords this formatter recognises — and the 20+ it doesn't

The formatter's keyword list is a fixed 11-entry array (SqlFormatterService in CoreToolServices.cs): SELECT, FROM, WHERE, GROUP BY, ORDER BY, INNER JOIN, LEFT JOIN, RIGHT JOIN, INSERT INTO, UPDATE, DELETE. These get uppercased and placed on their own lines. Everything else stays exactly as written, inline, wherever it appears in the original string. The practical impact: HAVING, AND, OR, UNION, CASE/WHEN/THEN/ELSE/END, WITH (CTEs), CROSS JOIN, FULL JOIN, ON, SET, VALUES, LIMIT, TOP, DISTINCT, and all window function keywords (OVER, PARTITION BY) receive no special treatment. A WHERE clause with five AND conditions lands on a single unbroken line after the WHERE is placed on its own — all five conditions run together without any line breaks between them. For straightforward SELECT / FROM / WHERE / ORDER BY queries this makes a meaningful readability improvement; for complex analytical SQL with CTEs, window functions, or CASE expressions the improvement is partial at best.

The other consequence: matching is substring-based, not word-bounded. A column or alias whose name contains one of those keywords — fromage, anywhere, username_update — will get a line break inserted mid-identifier. If your formatted output looks oddly broken in one specific spot, check nearby identifiers for an accidental keyword match before assuming the formatter is broken.

Worked example

This input:

select id,name from users where is_active=1 order by name

produces:

SELECT id,name
FROM users
WHERE is_active=1
ORDER BY name

Each recognised keyword is processed in turn — select first, then from, then where, then order by — with a line break and uppercasing inserted at every match. group by and the join/insert/update/delete keywords aren't present in this query, so they have no effect here. Notice id,name and is_active=1 are untouched: the formatter only acts on its 11 recognised keywords, not on commas, operators, or any other query structure.

Why SQL formatting matters for teams

Unformatted SQL is one of the most common sources of friction in database work. ORMs like Entity Framework and Hibernate generate single-line queries hundreds of characters wide. Query builders produce inconsistent capitalisation. Stored procedures written by different developers follow different indentation styles. When every developer formats SQL consistently, diff tools show meaningful changes rather than whitespace noise, code reviews focus on logic rather than presentation, and new team members understand queries faster.

How to format SQL queries online

1. Paste your SQL query — a SELECT, INSERT, UPDATE, DELETE, stored procedure, or any SQL statement — into the input editor.
2. Click Format.
3. The reformatted, indented SQL appears in the output panel.
4. Copy and paste it into your IDE, database client, or code review.

SQL formatting conventions

The most widely adopted SQL style conventions are:

• Uppercase keywords: SELECT, FROM, WHERE, JOIN, ON, GROUP BY, ORDER BY — uppercase makes keywords visually distinct from column and table names
• One clause per line: Each major clause starts on a new line at the same indentation level
• Indent subqueries: Nested SELECT statements are indented two or four spaces relative to the enclosing query
• Align join conditions: The ON keyword aligns with the corresponding JOIN for readability in multi-join queries
• Comma placement: Leading commas (at the start of each new column line) make it easier to add, remove, or comment out a column without touching the previous line

Understanding ORM-generated SQL

Modern ORMs — Entity Framework Core in .NET, Hibernate in Java, ActiveRecord in Ruby — generate SQL automatically from LINQ queries or model definitions. The generated SQL is syntactically correct and often optimised, but it is notoriously difficult to read as a single line. Pasting ORM output into this formatter immediately reveals the query structure, making it straightforward to identify missing indexes, N+1 query patterns, or unexpected Cartesian products from misconfigured joins. After formatting, you can compare the query against your expected execution plan and add database hints or rewrite the query in raw SQL if needed.

What this tool does not do

Formatting changes whitespace only — it does not validate SQL syntax, optimise query performance, or check that table and column names exist in your schema. For syntax validation, use your database client's explain or dry-run functionality. For performance, use EXPLAIN ANALYZE (PostgreSQL), SET SHOWPLAN_ALL ON (SQL Server), or your database's query profiler.