ARRAY expressions
Array literals, subqueries, offsets, safe offsets, and array functions can nest deeply. Indentation reveals which bracket or subquery belongs to each expression.
BigQuery query beautifier
Format GoogleSQL privately in your browser
The BigQuery profile loads by default. Choose your style, press Format SQL, and review the result without sending the query to a Google Cloud project or a remote formatting service.
Loading the BigQuery SQL formatter…
Enable JavaScript to format GoogleSQL locally. BigQuery syntax and review guidance remains readable below.
Readable queries without a cloud round trip
How to format BigQuery SQL
- 1
Paste the GoogleSQL source
Keep the original in version control and remove secrets or sensitive identifiers where practical. The editor accepts a query or script up to the documented local limit.
- 2
Confirm the BigQuery profile
Backticks occur in both BigQuery and MySQL, so punctuation alone is not reliable detection. Choose GoogleSQL because BigQuery is the actual target.
- 3
Review, dry run, and test
Diff the formatted text, then use BigQuery's validator or dry-run features and the intended project context to inspect syntax, referenced resources, permissions, and bytes processed.
GoogleSQL is not MySQL with cloud tables
Why BigQuery needs a dialect-aware SQL formatter
BigQuery's GoogleSQL dialect combines familiar relational clauses with nested and repeated data, cloud resource paths, analytic functions, scripting constructs, and warehouse-specific DDL and DML. A formatter must recognize the complete token before deciding where a comma, period, at sign, backtick, quote, or comment begins and ends.
Quoted identifiers use backticks. A fully qualified table can appear as `project-id.dataset.table`, where the project segment may contain a dash that would be an operator outside the quoted path. The formatter must preserve the backticks and path text. Changing those characters is not beautification; it can select another resource or produce invalid GoogleSQL.
GoogleSQL also supports raw, bytes, quoted, and triple-quoted literal forms. Literal chunks follow documented rules and may contain whitespace or punctuation that resembles SQL structure. The format engine should treat recognized literals as units and never alter their content. A diff remains necessary for newer features and templated code.
- Resource paths
- Backticks preserve project, dataset, table, and field identifiers.
- Named parameters
@namecan supply expression values, not identifiers.- Nested data
ARRAY,STRUCT, and repeated fields need visible nesting.- Post-window filter
QUALIFYfilters rows after window evaluation.
Make hierarchy visible
Format BigQuery arrays, structs, and UNNEST
STRUCT values
Typed and inferred structs group fields inside one value. Formatting should retain field order, aliases, types, and every nested expression.
UNNEST joins
UNNEST turns an array into rows and often appears with correlated joins. Layout can clarify the relationship but cannot prove that cardinality or null handling is intended.
Wildcard tables
Table wildcards and _TABLE_SUFFIX filters can affect scan scope. A formatter preserves them; BigQuery must determine which tables and bytes are touched.
Window-heavy queries benefit from structure
CTEs, windows, QUALIFY, and multi-statement scripts
Analytic workloads often layer common table expressions before a final aggregation or window calculation. Formatting can give each CTE a stable visual boundary and indent its select list, filters, joins, and grouping. It does not evaluate whether a CTE scans an avoidable partition range or whether a repeated transformation should be materialized.
QUALIFY filters the result of window functions and follows a different role than WHERE or HAVING. A BigQuery profile knows the keyword belongs to GoogleSQL query structure, while a generic formatter may treat it as an identifier. Window definitions should keep partitions, ordering, and frames visibly associated with the function they control.
BigQuery scripting adds declarations, variables, control flow, temporary functions, and multiple statements. The page can separate recognized statements, but it is not a full script debugger. Template layers such as dbt or Jinja should be formatted by tooling that understands the template, or after rendering representative compiled GoogleSQL.
No cost or bytes estimate
LiveParse has no project, table metadata, partitions, cluster columns, dry-run response, billing account, reservation, cache state, or query plan. Formatting cannot estimate bytes processed or cost.
Review Google's cost guidance →No BigQuery API call
Private formatting for warehouse queries
Local worker
Formatting happens in a disposable worker created by the page. It does not use the BigQuery REST API, Storage API, console, JDBC, ODBC, or a third-party query service.
No credentials
The page never asks for a Google Cloud account, service account, project, token, dataset, location, or billing configuration.
Resource limits
Input stops at 50,000 characters, a warning appears at 25,000, the worker is terminated after 2 seconds, and output above 200,000 characters is discarded.
Explicit export
The formatted result enters the clipboard or a local .sql file only when you choose those actions. Clipboard managers and device software are separate boundaries.
Formatting is presentation
What this BigQuery formatter does not validate
QuestionFormatter evidenceAuthoritative check
Is the grammar accepted?Only that the local formatter recognized enough tokens to lay out text.BigQuery validation or a dry run in the intended location and project.
Do resources exist?No dataset, table, routine, model, connection, or column catalog is available.The target project's metadata and permissions.
How much will it scan?No partitions, wildcard expansion, cache, or plan is known.Dry-run bytes plus query and cost controls.
Are results correct?Layout does not evaluate joins, nulls, cardinality, time zones, or business rules.Tests against representative data and reviewed expected results.
Questions answered
BigQuery SQL formatter FAQ
Does this formatter send a query to BigQuery?
No. Formatting runs inside the current browser tab and makes no BigQuery API request. The page has no project identity, credentials, dataset access, execution job, or billing context.
Does it support UNNEST and QUALIFY?
The BigQuery profile recognizes common GoogleSQL vocabulary including arrays, structs, UNNEST, window functions, and QUALIFY. New features and complex scripts can exceed a formatter's grammar, so inspect the diff and validate with BigQuery.
Does formatting estimate BigQuery cost?
No. The formatter has no table metadata, partitions, wildcard expansion, dry-run result, billing project, reservation, cache status, or execution plan. Use a BigQuery dry run and organizational cost controls.
Is formatted GoogleSQL guaranteed valid?
No. Verify syntax, datasets, tables, routines, types, locations, permissions, bytes processed, and results with the intended BigQuery project and supported tooling.
Why not use the MySQL profile for backticks?
Both dialects use backticks, but BigQuery adds cloud resource paths, nested data, UNNEST, GoogleSQL literal forms, QUALIFY, and other vocabulary that is not MySQL. Select the actual execution engine.
Can I format dbt or Jinja templates?
Template delimiters are a separate language layer. Format with template-aware tooling or format representative compiled GoogleSQL. Do not assume a query formatter understands macros, control flow, or compile-time substitutions.
Why does the tool stop on a large generated query?
Pathological inputs can use large amounts of memory. The page caps text at 50,000 characters and stops formatting after 2 seconds. Split a script only at safe statement boundaries and preserve dependency and transaction order.