How to Format SQL with Uppercase Keywords and Consistent Indentation

When SQL formatting is useful

SQL Formatter helps turn hard-to-scan SQL into a more structured presentation. When its parsing and formatting path succeeds, it reindents supplied SQL text and changes SQL keywords to uppercase. This is useful when preparing a query for review, documentation, or a code change where consistent layout makes clauses easier to follow.

The input includes the SQL text, an indentation value, and a dialect value. Indentation affects non-whitespace input, while the accepted dialect value does not activate dialect-specific parsing or formatting rules. The tool formats text rather than running a statement, connecting to a database, or checking whether a query produces the intended result, so database verification remains a separate task.

Steps for formatting a SQL query

1. Enter the SQL text. Supply the query as a string in the SQL input. Leaving that input empty uses its empty default. If the primary SQL input is empty, a non-empty value supplied through the older sql argument can be used instead. A value of another type is rejected, so provide text rather than a number, object, or list.

2. Choose the indentation value. The default indentation is 2. For non-whitespace SQL, the supplied value is converted to an integer before formatting. Converted values from 0 through 8 are used. If conversion fails, or if the converted value is below 0 or above 8, the formatter uses 2 instead. This setting behaves differently for whitespace-only input because that input returns before the conversion step and retains the supplied indentation value in the result.

3. Treat the dialect value as general input. You may provide a dialect value, but the formatting behavior described here does not use it to select vendor-specific parsing or layout rules. If the SQL relies on syntax associated with a particular database product, inspect the formatted text carefully and use the relevant database tooling for verification.

4. Start formatting. The tool parses the supplied text and formats it when that path succeeds. When one or more statements are parsed, the output places a semicolon and newline between statements and adds one trailing semicolon. This gives a predictable statement boundary in the returned formatted text, but it does not indicate that the database accepted the statements.

5. Review the returned text before reuse. Check names, operators, filters, joins, grouping, and statement boundaries against the purpose of the original query. Formatting changes presentation; it is not SQL execution or result validation. For non-empty input, keep the SQL within 1,000,000 UTF-8 bytes, because larger input is rejected before formatting. Text containing only whitespace is handled separately and produces an empty formatted result.

Reading the formatted output

A formatted response normally has clearer indentation and uppercase SQL keywords when parsing and formatting succeed. With multiple parsed statements, look for semicolon-and-newline separation and a final semicolon as part of the output shape. These visual characteristics describe how the text was presented, not whether its syntax suits a particular database or whether its execution would return the desired rows.

Whitespace-only input is a valid edge case: the resulting formatted text is empty. Non-empty input may fail when no SQL statements are detected, when the SQL parsing library is unavailable, or when an exception occurs while parsing or formatting. Such a failure identifies a formatting-path problem or an input condition rather than establishing a database result.

The dialect control should therefore be read as an accepted input, not as evidence of database-specific formatting. Before using a vendor-dependent query, compare the output with the intended structure and verify it through the appropriate database workflow. Manual review is also sensible when the precise treatment of comments, semantics, or round-trip preservation matters, because those properties are not described as guaranteed here.

Worked example

A developer is preparing a compact customer query for a code review and wants its structure to be easier to scan.

Enter select id, name from customers where active = 1, keep indentation at its default, and start formatting.

The returned text has uppercase SQL keywords, clearer indentation, and one trailing semicolon for the parsed statement.

Limitations

• The accepted dialect value does not apply dialect-specific formatting, and the tool presents supplied text instead of executing SQL or checking database results.

Common errors

• Formatting is rejected or fails: Confirm that the SQL value is a string, reduce non-empty input to no more than 1,000,000 UTF-8 bytes, and check that it contains a detectable SQL statement. If those checks are satisfied, parsing can still fail when the parsing library is unavailable or an exception occurs, so use the returned outcome as a formatting boundary rather than as database diagnosis.

FAQ

Does SQL Formatter run my query?

Formatting does not run the statement. It parses and presents the supplied SQL text when the formatting path succeeds, so use database tooling separately to check execution and returned data.

Does the dialect setting format PostgreSQL, MySQL, or another SQL dialect differently?

The value is accepted, but it does not select dialect-specific parsing or formatting rules. Vendor-specific syntax still needs careful review in the formatted output.

What happens if I submit an empty or unusable SQL input?

Whitespace-only text produces an empty formatted result, whereas non-empty input can fail if no SQL statements are detected or if parsing or formatting encounters a problem.