OnSumoTools

SQL Formatter

This tool formats and indents SQL queries directly in your browser. Paste a messy, single-line, or poorly indented query, and the tool returns a cleanly structured version with consistent indentation, keyword alignment, and line breaks. No data is sent to a server. Your queries, table names, and database logic stay on your device. The tool is free, requires no account, and works offline after the page loads.

Input

1 lines, 141 characters

Formatted output

Ready
SELECT u.id,
u.name,
o.total
FROM "users" u
INNER
JOIN "orders" o
ON u.id=o.user_id
WHERE o.total>100
AND u.active=1
ORDER BY o.total desc
LIMIT 10

11 lines, 147 characters

Formatting runs in your browser. SQL is not sent to a server.

How does the SQL Formatter (Multi-dialect) work step by step?

The SQL formatter parses and reformats SQL queries using a configurable style profile. Options include keyword capitalization (UPPERCASE or lowercase), indentation width (2 or 4 spaces), clause placement (each SELECT column on its own line or compact), JOIN formatting (indented or block), and subquery indentation depth. The formatter supports ANSI SQL plus dialect-specific syntax for PostgreSQL, MySQL, T-SQL (SQL Server), SQLite, BigQuery, and Snowflake. It identifies and aligns multi-column SELECT lists, places each WHERE clause condition on its own indented line, normalizes implicit comma-join syntax (SELECT a, b FROM t1, t2) to explicit INNER JOIN, and standardizes string delimiter style per the selected dialect. A diff mode displays original versus formatted SQL side by side for review before replacing your source. Key assumption: the formatter modifies whitespace, capitalization, and join syntax only. It does not execute queries, validate column or table names against a live schema, or detect SQL injection patterns. Edge case: SQL that mixes identifier quoting styles within a single query (for example, backtick identifiers alongside square-bracket identifiers) can cause the parser to misidentify identifier boundaries. Use the dialect-consistent quoting style for your target database throughout the query to avoid formatter parse errors.

What does a typical SQL Formatter (Multi-dialect) result look like?

A long JOIN query from your ORM logs arrives on one line. Paste it here, choose PostgreSQL and uppercase keywords, then copy the formatted SQL into your migration doc.

Frequently asked questions

  • Is my SQL query sent to a server?

    No. The formatter runs entirely in your browser using JavaScript. There is no network request when you paste and format a query. Your table names, column names, filter values, and any embedded credentials or tokens in comments stay on your machine. Verify this with your browser's DevTools Network tab.

  • Does it validate my SQL?

    No. The tool formats the structure of your query based on keyword recognition and parenthesis nesting. It does not check whether your tables exist, whether columns are valid, or whether the query would execute successfully. For validation, run the query against your database or use a linter like sqlfluff.

  • Which SQL dialects does it support?

    The formatter recognizes standard ANSI SQL keywords and additional keywords from PostgreSQL (RETURNING, ILIKE, LATERAL), MySQL (LIMIT, OFFSET without FETCH, backtick-quoted identifiers), SQLite (PRAGMA, EXPLAIN QUERY PLAN), SQL Server (TOP, NOLOCK, square-bracket identifiers), and Oracle (ROWNUM, CONNECT BY, START WITH). Dialect-specific keywords are formatted the same way as standard keywords.

  • Can it format CREATE TABLE and ALTER TABLE statements?

    Yes. DDL statements are formatted with column definitions indented inside the parentheses, one per line. Constraints (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK) are placed on their own lines at the same indentation level as columns.

  • Does it handle CTEs (WITH clauses)?

    Yes. Common Table Expressions are formatted with the WITH keyword at the base level, the CTE name and AS keyword on the same line, and the CTE query indented inside parentheses. Multiple CTEs are separated by commas with each new CTE starting on a fresh line.

  • What about stored procedures and PL/pgSQL blocks?

    The formatter handles basic BEGIN/END blocks and IF/ELSE/LOOP structures in procedural SQL. It indents the body of each block one level deeper. Complex procedural code with nested functions or dynamic SQL may not format perfectly, but the tool will not break the syntax.

Related tools

Make messy SQL readable

You copy a query out of a log and it's one long line. Or an ORM spits out something nobody can follow. Formatting fixes that. Keywords line up, clauses break onto their own lines and nested parts are indented.

Paste your SQL, choose a dialect and get a clean version back. You can set indent size and decide whether keywords should be upper or lower case.

Dialects matter

SQL isn't one language. MySQL, PostgreSQL, BigQuery and T-SQL each have their own quoting, functions and quirks. MySQL uses backticks. T-SQL uses square brackets. BigQuery has its own table path style.

Picking the right dialect lets the formatter treat those parts correctly instead of splitting them in odd places.

What it formats

SELECT queries, of course, along with CTEs written with WITH. CREATE TABLE and ALTER TABLE statements format fine as well, since they follow standard patterns.

Procedural blocks like stored procedures and PL/pgSQL code are trickier. Formatting depends on the exact syntax, so look at the result before you rely on it. Procedural code is where a formatter is most likely to make odd line breaks.

It doesn't validate

A formatter changes layout, not meaning. It won't tell you that a column doesn't exist or a join is wrong. A query that formats nicely can still fail when you run it. Treat the tool as a reading aid, and test the query against the database as usual.

Why formatting pays off

Readable SQL gets reviewed properly. A reviewer can spot a missing join condition when it's on its own line. Version control diffs stay small when everyone formats the same way, so a change to one filter doesn't rewrite the whole query.

  • One clause per line makes reviews quicker
  • Consistent keyword case avoids pointless diffs
  • Indented subqueries show structure at a glance

Privacy

Formatting happens in your browser. The query isn't sent to a server, which matters when table names or filter values hint at how your business works.