BigQuery SQL Formatter — Beautify GoogleSQL Queries in Your Browser

BigQuery's web console has no real format button. The only thing close is the auto-indent that fires when you press Enter, and that gets confused by STRUCT literals, ARRAY_AGG calls, and the ROWS BETWEEN clauses inside window functions. If you write any GoogleSQL longer than 50 lines, you end up reformatting by hand or copy-pasting into VS Code.

Our formatter handles BigQuery syntax natively. Pick the BigQuery dialect, paste your query, and you get clean output that respects how GoogleSQL works — STRUCT and ARRAY literals stay on appropriate lines, UNNEST joins format properly, and window functions get readable PARTITION BY / ORDER BY blocks. No upload, no GCP credentials, no signup.

Why BigQuery Console Does Not Have a Real Format Button

BigQuery has been promising a format-on-save feature for years. The closest thing today is the auto-indent that fires when you hit Enter — and it only handles basic SELECT/FROM/WHERE structure. Anything beyond that, you are on your own:

• STRUCT literals collapse onto one line — even when you have 8 fields with long expressions, the auto-indent gives up.
• ARRAY_AGG with ORDER BY inside — the inner ORDER BY does not align with the outer ones.
• UNNEST joins lose their hierarchy — UNNEST(array) AS item gets jammed onto the same line as the FROM clause.
• Window functions over partitions — ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW gets crammed onto a single line, making it impossible to read at a glance.
• WITH clauses stack without spacing — the auto-indent does not add blank lines between CTEs, so 10 CTEs become a wall of text.

The result is that BigQuery analysts develop one of two habits: either write everything by hand and never reformat, or paste into a third-party tool every time. Our formatter is the second option without the install step.

GoogleSQL Features Our Formatter Handles Cleanly

BigQuery (GoogleSQL) has some constructs that other dialects do not. Here is what our BigQuery dialect setting handles correctly:

STRUCT and ARRAY literals — STRUCT<name STRING, age INT64>('Alice', 30) keeps the type list on one line and the value list on the next when long, or stays compact when short.

UNNEST in joins — FROM table, UNNEST(items) AS item gets indented as a proper join, with the UNNEST on its own line.

Window functions with frame clauses — OVER (PARTITION BY user_id ORDER BY event_time ROWS BETWEEN 7 PRECEDING AND CURRENT ROW) gets readable line breaks at PARTITION BY, ORDER BY, and ROWS BETWEEN.

Qualified column names — project.dataset.table.column references stay on the same line and do not get word-wrapped at the dots.

Wildcard tables — FROM project.dataset.events_* WHERE _TABLE_SUFFIX BETWEEN '20240101' AND '20241231' formats with the wildcard intact.

Scripting blocks — DECLARE, SET, BEGIN/END, IF/ELSEIF, LOOP, RAISE — all the procedural BigQuery script constructs get nested indentation.

How to Format a BigQuery Query in Your Browser

1. Copy your query from the BigQuery console — Cmd+A inside the editor, then Cmd+C. Or grab it from your saved queries.
2. Paste it into the formatter input — accepts up to about 500KB of SQL text.
3. Set dialect to BigQuery — this is the option in the dialect dropdown that handles GoogleSQL-specific keywords correctly.
4. Pick indent — 2 spaces is the GoogleSQL convention — Google's own style guide uses 2 spaces. Match it for consistency with their docs.
5. Toggle uppercase keywords on — the BigQuery docs and most data team conventions use uppercase keywords.
6. Click Format — output appears with syntax highlighting. Copy back into the console or save to a .sql file.

If you are pasting into a dbt project, save the file to your models directory with a .sql extension. dbt will pick it up automatically on the next run.

Sell Custom Apparel — We Handle Printing & Free Shipping

Common BigQuery Formatting Pain Points This Tool Solves

The 50-column SELECT problem. Marketing analytics queries often have 30-50 columns from a wide events table. Our formatter puts each column on its own line with proper alignment, making it easy to spot duplicates and typos.

The nested CTE wall. Modern BigQuery queries chain 10+ CTEs. Without proper spacing, they read as one giant wall. Our formatter inserts blank lines between CTEs and indents each CTE body consistently.

The UNNEST join confusion. When you UNNEST an array column inside a join, the FROM clause becomes hard to parse. Our formatter pulls UNNEST onto its own line and shows the relationship visually.

The window function pile-up. Analytics queries often have 5-10 window functions in one SELECT. Each one gets its own block with PARTITION BY, ORDER BY, and frame clause on separate lines.

The procedural script mess. BigQuery scripts with DECLARE, SET, IF/ELSE, and CALL get nested properly so the control flow is visible at a glance.

Free Browser Formatter vs Paid BigQuery IDEs

Tool	Cost	BigQuery Format Quality	Privacy
Hawk SQL Formatter (this tool)	Free	Excellent — BigQuery dialect handles all GoogleSQL syntax	100% browser, no upload
BigQuery web console	Included	Basic auto-indent only	Stays in BigQuery
JetBrains DataGrip	$229/year	Strong, with BigQuery driver	Local install
VS Code + sql-formatter extension	Free + install	Good if configured for BigQuery dialect	Local
SQLFluff (CLI)	Free, requires Python	Excellent in CI workflows	Local
Looker Studio query editor	Free	None — text only	Hosted by Google

For one-off queries, the browser tool wins on speed. For team-wide consistency in a dbt project, install SQLFluff with the bigquery dialect and run it in your CI pipeline.

Other Browser Tools BigQuery Analysts Bookmark

BigQuery analysts spend a lot of time moving data between formats. These browser tools handle the most common conversions:

JSON formatter — when you query a JSON column from BigQuery and need to read the result, paste it into the JSON formatter for a tree view.

CSV to JSON converter — exporting a small BigQuery result as CSV and need it in JSON for a downstream API? Use the CSV to JSON converter.

YAML to JSON — dbt config files use YAML. Our YAML to JSON tool helps when you need to translate between formats.

Cron expression generator — BigQuery scheduled queries use cron syntax. Generate it visually instead of guessing field positions.

Frequently Asked Questions

Does this formatter understand BigQuery STRUCT and ARRAY syntax?

Yes. The BigQuery dialect setting handles STRUCT and ARRAY literals, ARRAY_AGG calls, UNNEST joins, and window functions with ROWS BETWEEN frame clauses. All of these get proper indentation and line breaks.

Will the formatter dry-run my query against BigQuery to validate it?

No. This is a text-only formatter — it does not connect to BigQuery or any GCP service. Your query stays on your device. To dry-run a query, use bq query --dry_run from the command line or click the validation button in the BigQuery console.

Can I format a dbt model that contains jinja templating?

The SQL portions format cleanly but jinja blocks like {{ ref(table) }} and {% for %} are not interpreted — they pass through as text. For full dbt-aware formatting, install SQLFluff with the dbt-bigquery plugin and run it from the command line.

Does the formatter handle BigQuery scripting (DECLARE, SET, BEGIN/END)?

Yes. All the BigQuery scripting constructs get proper nested indentation: DECLARE, SET, BEGIN/END blocks, IF/ELSEIF/ELSE branches, LOOP/WHILE constructs, and RAISE statements.

Why does my query look different after formatting?

The formatter reflows whitespace and applies consistent indentation. The actual SQL semantics are unchanged — only the formatting differs. If you want to verify, use the diff checker on the before and after versions.