SOQL Formatter

Why a generic SQL formatter doesn't work

SOQL looks enough like SQL that people reach for a SQL formatter, and then spend time undoing what it did.

The differences that break generic tools:

• Parent-child subqueries live inside the SELECT clause. A query like SELECT Id, (SELECT Id FROM Contacts) FROM Account has a nested query where SQL expects a column list. SQL formatters either flatten it onto one line or refuse to parse it.
• Relationships are traversed with dots, not joins. Account.Owner.Name reaches through two relationships in a single field reference. SQL formatters sometimes add spaces around the dots or treat the parts as separate tokens.
• Custom objects and fields carry suffixes. My_Object__c and My_Rel__r.Field__c must survive untouched, including their case. Some formatters lowercase identifiers by default, which breaks the query.
• Date literals aren't values. LAST_N_DAYS:30 and THIS_MONTH are SOQL keywords, not strings or numbers. A SQL formatter may put spaces around the colon, which makes the query invalid.
• Bind variables use a leading colon. :accountId is how Apex passes a variable into a query. Split the colon from the name and it stops working.
• There is no SELECT *. SOQL requires an explicit field list, so field-list handling matters more than in SQL, where the list is often short.

This formatter is built around those rules rather than adapted from a SQL one.

What the formatter does

It re-indents your query so the structure is visible: clauses on their own lines, the field list indented under SELECT, and subqueries as nested blocks with their own internal structure.

Conditions in the WHERE clause each go on their own line with the AND or OR at the start of the line rather than trailing. That alignment makes long conditions much easier to scan, and far easier to reorder or comment out while debugging.

You can choose indent size, whether keywords are uppercased, and whether the field list goes one per line or wraps. String literals are never touched — their contents pass through exactly as written, even if they happen to contain SOQL keywords.

Minify does the reverse, collapsing everything to a single line, which is what you want when pasting a query back into Apex or a config field.

Working with queries from Apex

A query copied out of Apex code usually arrives wrapped in quotes with escaped inner quotes, sometimes split across concatenated strings. Formatting that directly gives a mess.

Turning on "Input is an Apex string" strips the surrounding quotes, unescapes the inner ones, and joins simple concatenations before formatting, so you get the actual query. "Copy as Apex string" does the reverse, wrapping the formatted query back up when you're ready to paste it into code.

Note that a query built up dynamically from variables can't be fully reconstructed — the parts that come from variables at runtime aren't in the string you copied. For those, formatting the static portion and reasoning about the rest is usually the practical approach.

What validation can and can't tell you

Validation here is structural only. It checks things that are true of any SOQL query regardless of the org: balanced parentheses, closed string literals, a present FROM clause, fields in the SELECT, and clauses in a sensible order.

It cannot tell you whether Custom_Field__c exists on that object, whether a relationship name is correct, or whether the running user has access to a field. All of that depends on the org's schema and the user's permissions, and can only be checked against a real org — through the Developer Console, an IDE connected to the org, or the API.

So a query that validates here can still fail when you run it. What validation does catch is the class of mistakes that are quick to make and slow to spot by eye, particularly unbalanced brackets in a query with several subqueries.

A few SOQL formatting habits worth having

• Put each field on its own line for long field lists. A query selecting twenty fields is far easier to review, and version-control diffs become readable — you see the one field that changed rather than one enormous modified line.
• Lead WHERE conditions with the operator. Starting lines with AND or OR rather than ending them makes it obvious where each condition begins, and lets you comment one out without touching the line above.
• Uppercase keywords, leave everything else alone. Uppercase SELECT, FROM and WHERE makes the structure pop against the field names. Object and field names should keep the casing they have in the schema.
• Always consider a LIMIT while developing. It's easy to run an unbounded query against a large object by accident. The summary above flags whether your query has one.

Frequently asked questions

Is my query sent to a server?

No. Formatting happens entirely in your browser. Your queries — including any field names, record IDs, or business logic they contain — never leave your device.

Does it validate against my org's schema?

No. Validation is structural only: brackets, quotes, clause order, and similar. Whether an object or field actually exists depends on your org, and can only be checked by running the query against it.

Does it handle subqueries?

Yes. Parent-child subqueries inside SELECT and semi-joins in WHERE are both formatted as nested blocks, including when nested more than one level deep.

Will it change my field names?

No. Field names, object names, relationship paths and string literal contents are preserved exactly. Only keyword casing changes, and only if you choose that option.

Can I paste a query straight from Apex?

Yes — turn on "Input is an Apex string" to strip the surrounding quotes and unescape inner ones before formatting. Use "Copy as Apex string" to wrap the result back up for pasting into code.

Does it work with SOSL?

No, this handles SOQL only. SOSL has a different syntax and would need separate support.

Is it free?

Yes, completely free with no sign-up.