Skip to content
YAS.SH
Developer🔒 Browser (client-side)API: browser-only📴 Works offlineintermediate

SQL Formatter

Formats SQL queries for readability — entirely in your browser.

Data stays in your browser
Ready to runInstant execution
All tools →
Result

What does this tool do?

Formats SQL queries for readability — entirely in your browser.

Why would I use it?

  • You are debugging a long query and want it readable.
  • You want consistent formatting before committing SQL.
  • You want to avoid uploading query text to a server.

Real-life example

Input
SELECT a,b FROM t WHERE a=1 AND b=2
Output
SELECT a, b
FROM t
WHERE a = 1
  AND b = 2

Keywords, clauses and commas are aligned.

Input → Process → Output → Next

Input
Paste SQL.
Process
The browser tokenizes and reformats the query.
Output
Formatted SQL.
Next action
Copy it back to your editor.

Common mistakes

  • Expecting dialect-specific features (CTEs, window functions) to format perfectly.
  • Formatting non-SQL text and getting surprising output.
  • Pasting credentials into SQL strings into public tools — this one stays local.

What the result means

Formatting is cosmetic — the query semantics are unchanged.

Privacy & security

Your input is processed entirely in your browser and never sent to a YAS server.

API automation is not supported for this tool. Runs client-side — SQL text must not leave your browser. This tool intentionally cannot be executed through the YAS API (server-side).

API

No public API for this tool

This tool runs in your browser and cannot be executed through the YAS API. Runs client-side — SQL text must not leave your browser.

SQL Formatter: technical reference, use cases and FAQ

How SQL Formatter works

The statement is tokenised into keywords, identifiers, literals, operators and comments, then re-emitted with keywords uppercased and clauses placed on their own lines with consistent indentation. Nested subqueries and parenthesised expressions increase the indent level, JOIN conditions are aligned under their JOIN, and comma-separated select lists are broken so that adding a column produces a one-line diff.

Formatting is purely lexical. The formatter does not parse the query into a relational algebra tree, connect to a database or know your schema, so it cannot tell you whether a column exists, whether a join is valid, or how the planner will execute it. Any statement that tokenises will be formatted, including one that the server would reject.

When to use it: real-world scenarios

Reading a query generated by an ORM

ORM output arrives as one long line with generated aliases. Formatting reveals the join order and the actual predicates, which is where N+1 and accidental cross joins become visible.

Preparing a query for code review

Consistent formatting makes the logical structure — which conditions belong to which clause — reviewable without mentally re-parsing the text.

Debugging a query returning wrong rows

Indentation exposes operator precedence mistakes: an OR at the wrong nesting level inside a WHERE clause is nearly invisible on one line and obvious once formatted.

Standardising SQL in migrations and stored procedures

Formatting every statement the same way turns migration diffs into semantic diffs, which matters when reviewing schema changes under time pressure.

Pro tips

  • Format before you EXPLAIN. Reading a plan against a formatted query is far easier when you can point at the exact clause a node corresponds to.
  • Watch for mixed AND/OR without parentheses. AND binds tighter than OR, and formatting makes the resulting grouping visible rather than assumed.
  • Never paste production data values into a shared formatter. Replace literals with placeholders first — this is a habit worth having regardless of where the tool runs.
  • Keep formatting consistent with your team's linter (sqlfluff, pgFormatter) so the tool does not fight your CI.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

  • Dialect differences are not fully modelled. T-SQL square-bracket identifiers, MySQL backticks, PostgreSQL dollar-quoted bodies and Oracle hints may format imperfectly.
  • No syntax validation: an invalid statement is formatted, not rejected. The formatter is not a linter.
  • Vendor-specific procedural blocks (PL/pgSQL, T-SQL batches with GO) are treated as text and may lose their internal structure.
  • This tool runs in your browser and has no server API, so it cannot be scripted through the YAS API.

Frequently asked questions

Which SQL dialects are supported?
Standard SQL constructs common to PostgreSQL, MySQL, SQL Server and SQLite. Highly vendor-specific syntax — dollar-quoted function bodies, T-SQL batch separators, Oracle hints — may not format cleanly.
Does formatting change what my query does?
No. Only whitespace, line breaks and keyword casing change. Identifiers and literals are emitted verbatim, including their original case, because quoted identifiers are case-sensitive in most engines.
Will it tell me if my SQL is invalid?
No. It formats what tokenises; validation requires a parser for your specific dialect and, for name resolution, your schema.
Is my query sent to a server?
No. Formatting is browser-only for exactly this reason — queries routinely contain table names, business logic and sometimes literal customer data.
Ask YAS AI
🍪 Cookies & privacy. Essential cookies keep you signed in and remember language and theme. Google AdSense and reCAPTCHA are Google technologies: AdSense runs only after Accept All; reCAPTCHA loads on sign-in and contact forms. See how Google uses data: https://policies.google.com/technologies/partner-sites cookie policy · privacy policy.
Settings