Pasted or generated SQL is often written as a single unbroken line, or with inconsistent indentation across joins, subqueries and conditions — this makes it slow to review before running against a database. Formatting re-indents keywords, clauses and nested queries so the structure of the statement is easy to scan.
Pick a dialect to match the database you're targeting — dialects differ in supported syntax (e.g. LIMIT vs TOP, backtick vs double-quote identifiers), which affects how the formatter parses and re-indents certain statements.
Formatting happens entirely in your browser using the open-source sql-formatter library — nothing is sent to a server.
Why does the dialect matter?
SQL dialects differ in syntax details — for example MySQL uses backticks for identifiers while PostgreSQL uses double quotes, and LIMIT/TOP clauses vary — picking the right dialect helps the formatter parse dialect-specific syntax correctly.
Does this validate my SQL?
No — it reformats whitespace and indentation around the tokens it recognizes, but it does not check that the query is semantically valid or would run against a real database.
Is my SQL sent to a server?
No — formatting runs entirely in your browser using the open-source sql-formatter library.