Turn one-line, unreadable SQL into a properly indented query — 18 dialects, all in your browser.
SQL rarely arrives readable: one endless line out of an ORM, every keyword lowercase in a slow-query log, the indentation destroyed by a chat client. Reformatting it by hand before you can even read it wastes ten minutes — and the reading is where the bugs are: a join condition that quietly became a filter, an OR that binds wider than its author thought, a subquery three levels deep. Paste it here and it comes back with one clause per line, aligned nesting and keywords in the case you prefer.
The work is done by a real parser, not a pile of regular expressions. The query is tokenized, understood as a tree of clauses and printed again, which is why comments stay on the line where they were written, string literals survive untouched even when they contain words like SELECT or FROM, and a window function keeps its OVER (PARTITION BY … ORDER BY …) block properly nested. Eighteen dialects are offered — Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, Spark, Trino, Hive, Db2, Db2 for i, TiDB, SingleStore and N1QL — and the choice is not decoration: PostgreSQL dollar-quoting ($$body$$) and T-SQL brackets ([dbo].[table]) are parse errors under Standard SQL and format perfectly under the right dialect. Placeholders such as ?, :name, $1 and @name are recognised in every dialect and passed through verbatim, so SQL copied straight out of a query log is not mangled.
Two honest limits. The formatter only checks that the text is grammatically valid SQL for the chosen dialect: it knows nothing about your tables, so it will format a query referencing a column that does not exist, and it never runs anything. When the text cannot be parsed it says where the parser gave up, with line and column, instead of returning a half-formatted mess. Privacy is the reason to format here rather than on a random site: production queries carry table names, business logic and sometimes personal data. The library (sql-formatter, MIT, served from vai.la and downloaded only on your first format) runs inside your browser.
No. The query is parsed and reprinted by JavaScript on your own device — nothing is uploaded, logged or stored. That matters, because real queries expose your schema, your business rules and sometimes personal data sitting in literals. After the first format you can disconnect from the internet and it still works.
The one your database speaks. Standard SQL covers most ordinary queries, but database-specific syntax needs the matching dialect: [brackets] need SQL Server (T-SQL), $$dollar quoting$$ needs PostgreSQL. A parse error on valid SQL is usually fixed by switching the dialect.
No. Only whitespace, line breaks and the case of keywords change. Identifiers, string literals, numbers and comments come back exactly as typed, so the formatted query is equivalent to the original.
Because the parser hit something it could not fit into the grammar, at the line and column shown. Three usual causes: a typo such as a missing comma, quote or parenthesis; a fragment that is not a complete statement; or database-specific syntax with the wrong dialect selected.
Yes. Positional (?), numbered ($1) and named (:name, @name) placeholders are recognised in every dialect and printed back unchanged, so you can paste straight from a query log or a framework's debug output.
Yes. Statements separated by semicolons are formatted one after another, with a blank line between them. The input is capped at 300,000 characters so the page never freezes; beyond that, split the file.
Vai.la turns any URL into a short link with click statistics, QR Code and your own biolink.
Vai.la is not responsible for how the tools are used or for decisions made based on their results.