Skip to content
Spellkit

SQL Formatter

Beautify SQL queries per dialect or minify to one line — all in your browser.

Formatting runs locally — your query never leaves this browser.

What is SQL Formatter?

SQL Formatter beautifies SQL queries with the keyword case and indentation you choose, or minifies them to a single line. It understands eleven dialects — MySQL, PostgreSQL, SQLite, MariaDB, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Spark, Hive, and standard SQL — so dialect-specific syntax like [brackets] and `backticks` formats correctly. Everything runs in your browser: queries are never uploaded.

Key features

  • Eleven dialects: MySQL, PostgreSQL, SQLite, T-SQL, PL/SQL, BigQuery, Snowflake and more
  • Keyword case control — UPPERCASE, lowercase, or keep as typed
  • Indent with 2 spaces, 4 spaces, or tabs
  • One-click minify collapses a query to a single line (string literals kept intact)
  • Runs entirely in your browser — queries never leave your machine

SQL Formatter — beautify & minify queries online

A query pasted from a log, an ORM, or a colleague usually arrives as one dense line with inconsistent casing. This tool parses it and prints it back cleanly — keywords cased the way your team prefers, each clause on its own line, and nested expressions indented — or does the reverse and collapses it to a single line for embedding in code. Everything happens in your browser; queries are never uploaded, which matters when they carry real table and column names.

Pick the right dialect first

The formatter understands eleven dialects: standard SQL, MySQL, PostgreSQL, SQLite, MariaDB, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Spark SQL, and Hive. This isn't cosmetic — the dialect tells the parser how to read syntax that's unique to each engine. [bracketed identifiers] are valid in T-SQL, `backticks` in MySQL, and :: casts in PostgreSQL; choose the wrong dialect and the parser can misread those tokens and format around them incorrectly. When in doubt, "Standard SQL" handles the common ANSI subset most queries stay within.

Formatting options

  • Keyword case — render SELECT, FROM, JOIN in UPPERCASE, lowercase, or leave them exactly as typed if your codebase has a house style you don't want touched.
  • Indent — 2 spaces, 4 spaces, or tabs, to match whatever your editor and linter expect.
  • Multiple statements separated by ; are all formatted together, with a blank line between each for readability.

Press Load sample to see it in action on a realistic query — a join across users and orders with GROUP BY, HAVING, ORDER BY, and LIMIT — which is a quick way to preview how your chosen options look before pasting your own.

Minify does the opposite

Minify strips a query down to one line for logs, string literals in application code, or a compact commit. It's careful about what it removes:

  • Runs of whitespace collapse to a single space.
  • -- line comments are dropped, because on one line they would swallow everything after them.
  • /* block comments */ are kept, since they're safely delimited.
  • Whitespace inside 'string literals' is never touched, so 'New York' stays intact rather than becoming 'NewYork'.

Good to know

  • It formats, it doesn't validate or run. The tool reshapes your SQL's layout; it won't tell you whether a column exists, whether a join is correct, or whether the query will execute. A query that formats cleanly can still be logically wrong.
  • If it can't parse, it says so. Badly broken SQL — an unclosed parenthesis, a stray keyword — produces a parse error rather than mangled output. That error is often itself a useful hint that something upstream is malformed.
  • Formatting is idempotent-ish. Run an already-formatted query through again with the same settings and you get the same result, so it's safe to wire into a pre-commit habit.

Privacy

Parsing, formatting, and minifying all run in a parser loaded into your browser. Queries are never uploaded, logged, or stored — so it's safe to paste production SQL, complete with real schema names, without it leaving your machine.

Frequently asked questions

Why do I have to pick a dialect?
The dialect tells the parser how to read engine-specific syntax such as [brackets] in T-SQL, backticks in MySQL, and :: casts in PostgreSQL. Pick the wrong one and those tokens can be misread and formatted incorrectly; Standard SQL covers the common ANSI subset when you are unsure. Eleven dialects are supported, from MySQL and PostgreSQL to BigQuery, Snowflake, and Hive.
Can I keep my own keyword casing?
Yes. Set keyword case to as typed and SELECT/from are left exactly as written; the other options force UPPERCASE or lowercase. Indentation can be 2 spaces, 4 spaces, or tabs to match your editor.
What exactly does Minify do to comments and strings?
It collapses whitespace to single spaces and drops -- line comments, which would otherwise swallow the rest of the line, but keeps /* block comments */ and never touches whitespace inside 'string literals', so 'New York' stays intact.
Does the formatter check whether my query is valid or correct?
No, it reshapes layout only. It will not tell you if a column exists or a join is right, and a query that formats cleanly can still be logically wrong. Genuinely broken SQL produces a parse error rather than mangled output.
Is it safe to paste production SQL with real table names?
Yes. Parsing and formatting run in a parser loaded into your browser, so queries are never uploaded, logged, or stored and real schema names never leave your machine.
Can it format several statements at once?
Yes. Statements separated by ; are all formatted together with a blank line between each. Press Load sample to preview the styling on a realistic join with GROUP BY and HAVING before pasting your own.

Privacy

Formatting and minifying are done by a parser running locally in your browser; your queries — which may contain table or column names from a real schema — are never uploaded.