This page is the canonical guide to formatting and minifying SQL in the browser with DevUtilities. Use the SQL Formatter above while you read, or jump to a topic below. All parsing and formatting runs in your browser via sql-formatter — queries, schema names, and sample data are never uploaded.

SQL Formatter beautifies multi-line SQL for humans and minifies SQL for transport. It uppercases keywords automatically (SELECT, FROM, WHERE), applies clause-aware indentation, and respects dialect-specific grammar from the sql-formatter library — the same engine used by many IDE extensions and CLI formatters.

What you get

• Symmetric dual-pane workspace: SQL query input on the left, formatted or minified output on the right
• 13 dialect parsers grouped as Core relational, Cloud warehouses, Big data, and Enterprise
• Beautify and Minify modes with live auto-format (debounced) and an explicit Process button
• Dialect picker and Strip comments toggle in the panel header — no extra row stealing editor height
• Collapsible formatted output for large SELECT trees (Beautify mode)
• Parse errors with line and column hints when the dialect parser cannot read your input
• Optional URL sharing: ?mode=minify&dialect=postgresql persists mode and dialect

Use this tool when

• You paste ad-hoc SQL from a log, BI tool, or ORM and need readable indentation before review
• You embed SQL in application code and want a one-line minified string
• You work across PostgreSQL, Snowflake, BigQuery, Spark, or Oracle and need the parser to recognize dialect keywords
• You want to strip block and line comments before committing or shipping a query

Do not expect

• Semantic validation — formatting success does not mean the query will execute on your server
• Automatic query planning, linting for performance, or schema-aware rewrites
• Perfect preservation of every exotic vendor extension not covered by the selected dialect
• Server-side EXPLAIN or execution — this is a layout and whitespace tool only

Controls live in the SQL QUERY panel header so input and output editors stay the same height. There is no separate options row below the toolbar.

Keyboard shortcuts

• Ctrl/Cmd+Enter — Process
• Ctrl/Cmd+L — Clear workspace

Always pick the dialect that matches where the query will run. The parser uses different keyword lists, function names, and comment rules per dialect. Standard SQL is a safe default for generic ANSI-style snippets.

Cassandra CQL is not supported — it is not part of the sql-formatter dialect set. Use a CQL-specific formatter for Cassandra workloads.

Beautify and Minify share the same dialect picker and Strip comments checkbox but produce different output shapes.

Example

Input: select id, name from users where active = 1 — Beautify yields indented lines with SELECT / FROM / WHERE uppercase. Minify with Strip comments off yields a single line: select id, name from users where active = 1.

1. Open SQL Formatter from the sidebar under Formatters.
2. Paste SQL into the left editor, upload a .sql file from the session toolbar, or drag and drop a file onto the empty state.
3. Choose the dialect that matches your database (e.g. snowflake for a Snowflake worksheet query).
4. Optionally check Strip comments if the input contains -- or /* */ annotations you do not want in output.
5. Select Beautify for readable SQL or Minify for a compact single line.
6. Review output on the right. Fix any parse error banner — click to dismiss after editing the input.
7. Copy, download, or swap output back to input for another pass.
8. Share a link with ?dialect=bigquery&mode=minify when you want collaborators to open the same settings.

Flyway, Liquibase, and ORM migration files are easier to review when SELECT lists, JOIN blocks, and WHERE clauses break onto consistent lines.

Workflow

1. Set dialect to postgresql, transactsql, mysql, or sqlite to match your migration target.
2. Paste the raw migration SQL from a generated diff or ORM output.
3. Beautify with Strip comments off if inline comments document intent.
4. Copy formatted SQL back into the migration file before opening the PR.

Tip

Formatting does not validate against your live schema. Run migrations in a staging database after cosmetic changes.

Analytics engineers often copy SQL from Snowflake, BigQuery, or Redshift consoles with inconsistent casing and collapsed lines.

Snowflake / BigQuery / Redshift

• Select snowflake, bigquery, or redshift before Beautify so warehouse-specific functions parse correctly.
• Use Strip comments when exporting from a notebook that includes -- session notes.
• For very wide SELECT lists, use the output fold controls (Expand all / Collapse all) after Beautify.

Spark / Trino / Hive

• Pick spark for Databricks notebooks and Spark SQL pipelines.
• Pick trino for Presto-compatible federated queries across catalogs.
• Pick hive for legacy HiveQL scripts — parser coverage follows sql-formatter Hive dialect rules.

Application code often stores SQL as a template string. Minify reduces bytes and escapes when you need one line inside JavaScript, Python, or Go source.

1. Paste the readable SQL version into the input panel.
2. Enable Strip comments if developers left debugging notes in the query.
3. Switch to Minify mode.
4. Copy the single-line output into your string literal (watch quote escaping in your language).

If you need readable SQL in source but compact SQL at runtime, keep the beautified version in docs and minify only for the build artifact.

Normalize SQL before review so diffs focus on logic, not whitespace noise.

• Beautify both sides of a comparison when a teammate pastes one-liner SQL into a ticket.
• Use uppercase keywords as a consistent style — the formatter applies this automatically in Beautify mode.
• Pipe output from Text Diff after formatting two versions if you need a semantic diff of query text.

The Strip comments checkbox applies to both Beautify and Minify. When enabled, the tool removes comments before formatting using dialect-aware rules where implemented.

When Strip is off (Minify)

Minify still collapses whitespace to a single line but keeps comment text in place. Use this when comments must ship with the query.

When the parser fails, a red banner shows Parse error with line and column numbers. The input editor highlights the error line when available.

Common fixes

1. Wrong dialect — switch to the engine you actually use (e.g. plsql for Oracle packages, not Standard SQL).
2. Unclosed string or parenthesis — balance quotes and parentheses near the reported line.
3. Trailing comma or incomplete clause — finish SELECT lists and CTEs before formatting.
4. Non-SQL pasted — remove shell or JSON wrappers around the query.
5. Dialect-specific syntax in generic mode — try the vendor dialect or simplify unsupported extensions.

If a valid query still fails, the sql-formatter parser may not cover that syntax variant. Report upstream or format a simplified subset manually.

SQL Formatter runs 100% in your browser. The sql-formatter library is loaded dynamically; formatting executes on the main thread in JavaScript.

• No query text is sent to Dev Tools Suite servers
• Input, output, dialect, and Strip comments preference can persist in localStorage on your device
• URL query params (?dialect=, ?mode=) only reflect settings — they do not contain your SQL body
• Clear the workspace (Ctrl/Cmd+L) after working with production data or PII

• Match dialect to execution environment before Beautify — formatting success ≠ runtime success
• Use Beautify for humans, Minify for machines
• Keep Strip comments off when comments document business rules; turn on for exports and embedded strings
• Verify minified output on a staging database when dollar-quoted strings or exotic literals are present
• Use session history and file upload for large scripts instead of pasting into chat apps that alter quotes
• Combine with Text Diff when comparing two formatted versions of the same report query