SQL Formatter

Reflow SQL clauses and lists without rewriting quoted text or comments.

SQL input

Quoted strings, quoted identifiers, line comments, block comments, and PostgreSQL-style dollar-quoted bodies are protected before spacing and keyword changes are applied.

Characters

Lines

Statements

Joins

Layout choices

Keyword Case

Indent Size

Comma Style

Break before JOINPlace JOIN clauses on their own lines.Break AND / OR conditionsIndent top-level boolean continuations for faster scanning.Case common functionsApply the selected keyword case to names such as COUNT and COALESCE.

Advanced SQL Beautifier

Clause snapshot

Counts ignore protected strings and comments, so words such as SELECT inside a message do not inflate the result.

SELECT

WHERE

GROUP BY

ORDER BY

Formatted SQL output

Formatted SQL will appear here.

Formatting is not SQL validation. SQL dialects disagree about keywords, operators, quoting, procedural blocks, and extensions. Review important output in the database engine that will actually parse it.

Formatting runs in this browser session. The page does not connect to a database, execute the query, or send the SQL to Yoryantra.

Why SQL quotes and comments need protection

When you format SQL, the words inside a quoted string or a comment should stay exactly as written. Even the semicolon inside 'message; still text' is part of the message, not the end of a statement. This formatter sets those parts aside, formats the SQL around them, and puts them back unchanged.

The same approach protects PostgreSQL dollar-quoted text, MySQL-style names in backticks, and SQL Server-style names in square brackets. It helps preserve those parts of a query, but it does not mean the formatter understands every database dialect.

What the formatter changes

Selected keyword casing outside protected text.
Spacing around common comparison operators and commas.
Line breaks around major clauses, joins, and optional AND / OR continuations.
Top-level SELECT-list commas when they can be separated without entering parentheses or protected text.

It does not execute SQL, resolve schemas, validate column names, infer a database dialect, or prove that the formatted statement is semantically equivalent. Keyword-versus-identifier meaning can require a real dialect parser.

Keep the line break after a -- comment

When you write -- comment, the comment ends at the next line break. If a formatter removes that break, it can turn the next SQL clause into part of the comment. Yoryantra keeps the line break in place.

Data-changing statements deserve a second check

The tool flags some UPDATE or DELETE statements with no outer WHERE clause, even when a nested query contains WHERE. It also flags SELECT *. These warnings are reminders, not a safety check: database-specific syntax and dynamic SQL can still need closer review.

A formatting example that preserves literal text

Before:
select id,note from logs where note='select a,b; from text' and active=true;

After:
SELECT
  id,
  note
FROM logs
WHERE note = 'select a,b; from text'
  AND active = true;

Why PostgreSQL's lexical documentation is a useful reference

PostgreSQL's current lexical structure documentation gives concrete examples of tokens, quoted identifiers, string constants, dollar quoting, statement semicolons, and both line and block comments. It is referenced here for lexical behavior the formatter protects, not as a claim that PostgreSQL syntax represents every SQL implementation.

When the advanced formatter is the better fit

This page keeps the control set intentionally narrow. Minification, comment-removal choices, alternate output forms, and deeper diagnostics belong in the SQL Beautifier / Minifier.