Format SQL locally with an explicit Standard SQL, PostgreSQL, MySQL, SQLite, SQL Server, Oracle PL/SQL, or BigQuery grammar. Choose 2, 4, or 8 spaces and preserve, uppercase, or lowercase recognized keywords. The selected sql-formatter grammar changes layout without connecting to a database, executing a query, inspecting a schema, or proving syntactic or semantic validity. Unsupported stored routines and custom delimiters fail closed, input stays in the browser, and deployment still requires a semantic diff plus tests against the actual database version.
Continue with a related workflow or open the next tool that usually follows this task.
SQL formatting can expose joins, predicates, grouping, and subqueries, but readable output is not evidence that a statement is valid or safe. This workflow identifies the target database and version, preserves and redacts the source, applies one explicit formatter grammar, reviews exact token and comment changes, and then verifies schema resolution, permissions, result sets, plans, transactions, migrations, tests, and rollback in the real toolchain.
OpenRelated toolFormat, minify, and syntax-check eight code and data languages locally with parser-specific engines.
OpenRelated toolCompare bounded text locally with exact line hunks, code-point highlights, and unified patch export.
OpenRelated toolBeautify or minify strict JSON locally while preserving duplicate keys and number text.
OpenChoose the database grammar that will consume the query; use Standard SQL only when no vendor-specific syntax is present.
Remove passwords, tokens, personal data, customer values, and proprietary literals, then paste or upload SQL within the documented limits.
Choose preserve, uppercase, or lowercase keyword casing and select 2, 4, or 8 spaces for indentation.
Run the formatter in the default Manual mode; use Live mode only for small, non-sensitive fragments that already parse cleanly.
If parsing fails, check the selected dialect and unsupported stored-routine or custom-delimiter syntax instead of deleting source tokens blindly.
Compare the output with the original, then copy or download it and verify behavior, schema, permissions, plan, and tests in the real database toolchain.
Lay out joins, nested filters, CTEs, grouping, and ordering so a reviewer can compare logical clauses without reading one long line.
Format a copied PostgreSQL, MySQL, SQLite, T-SQL, PL/SQL query statement, or BigQuery query with the matching grammar before debugging it in the vendor console.
Normalize non-secret query fixtures for documentation and tests while retaining comments, parameters, literals, and semicolons for comparison.
Compare formatter versions or team settings by recording dialect, casing, indentation, input bytes, and exact downloaded output.
Make a query structure easier to discuss before using the database's own parser, EXPLAIN, schema checks, permissions, and application tests.
Standard SQL cannot interpret every vendor extension. Choose PostgreSQL for casts and dollar parameters, SQL Server for bracketed identifiers and T-SQL variables, or the other matching grammar before treating a parse error as broken source.
Readable output proves only that the selected whitespace formatter accepted the tokens. It does not resolve tables, verify types, check permissions, inspect an execution plan, or prove that an incomplete statement will run.
The formatter intentionally rejects stored procedure, function, trigger, and custom DELIMITER workflows. Use the database vendor's parser or IDE for those scripts instead of removing syntax until a generic formatter accepts it.
Formatting may move comments and whitespace. Review a semantic diff, keep the original, and execute tests or EXPLAIN in a non-production environment before replacing a query used by an application or migration.
Local processing avoids an intentional query upload, but browser extensions, clipboard history, screenshots, and the device can still expose pasted values. Redact credentials, personal data, tenant IDs, and proprietary literals first.
A join, filter, aggregation, and ordering become separate reviewable clauses while the string literal remains unchanged.
select c.id, c.name, count(o.id) as order_count from customers c left join orders o on o.customer_id = c.id and o.status = 'paid' where c.active = true group by c.id, c.name having count(o.id) > 2 order by order_count desc;SELECT
c.id,
c.name,
count(o.id) AS order_count
FROM
customers c
LEFT JOIN orders o ON o.customer_id = c.id
AND o.status = 'paid'
WHERE
c.active = TRUE
GROUP BY
c.id,
c.name
HAVING
count(o.id) > 2
ORDER BY
order_count DESC;Selecting PostgreSQL recognizes a positional parameter, cast operator, and CTE structure that the generic grammar may not interpret correctly.
with recent as (select user_id, created_at from events where created_at >= $1::timestamptz) select user_id, max(created_at) as last_seen from recent group by user_id;WITH
recent AS (
SELECT
user_id,
created_at
FROM
events
WHERE
created_at >= $1::TIMESTAMPTZ
)
SELECT
user_id,
max(created_at) AS last_seen
FROM
recent
GROUP BY
user_id;The SQL Server mode retains bracketed names and the @status parameter while laying out TOP, WHERE, and ORDER BY.
select top (10) [Order ID], [Customer Name] from [Order Details] where [Status] = @status order by [Order ID] desc;SELECT
TOP (10) [Order ID],
[Customer Name]
FROM
[Order Details]
WHERE
[Status] = @status
ORDER BY
[Order ID] DESC;A line comment, backtick identifiers, JSON path, and SQL words inside a string are retained when MySQL is selected.
-- keep this review note
select `order`, json_extract(payload, '$.id') as event_id from `events` where message = 'select from';-- keep this review note
SELECT
`order`,
json_extract(payload, '$.id') AS event_id
FROM
`events`
WHERE
message = 'select from';The implementation uses sql-formatter 15.8.2 and passes one explicitly selected dialect object to its tokenizer and layout engine. It does not guess a dialect from the input.
Seven modes are exposed: Standard SQL, PostgreSQL, MySQL, SQLite, SQL Server Transact-SQL, Oracle PL/SQL, and BigQuery. Dialect selection controls recognized identifiers, parameters, operators, functions, and keywords.
The formatter changes whitespace and can preserve, uppercase, or lowercase recognized keywords and data types. Function and identifier casing remain preserved; quoted strings, quoted identifiers, comments, placeholders, and statement semicolons remain source tokens.
A formatter parse is narrower than database validation. It may reject an unsupported token with a safe line and column, yet it can also lay out an incomplete or semantically invalid statement. It never connects to a schema, executes a query, or returns an execution plan.
Input is bounded before parsing to 1,000,000 UTF-8 bytes, 20,000 lines, and 100,000 UTF-8 bytes per line. NUL text, leading custom DELIMITER directives, and leading stored routine or trigger definitions fail closed.
Processing, copying, and SQL file creation stay in the browser. Telemetry is limited to coarse operation metadata and stable errors; query text and formatted output are not added to analytics events.
The selectable grammars are Standard SQL, PostgreSQL, MySQL, SQLite, SQL Server Transact-SQL, Oracle PL/SQL, and Google BigQuery. Select the database explicitly; there is no automatic dialect detection.
No. This is a whitespace formatter backed by sql-formatter 15.8.2, not a database parser, compiler, schema checker, linter, or query executor. It can report some token and delimiter parse failures, but accepted output can still be incomplete, invalid for your server version, or semantically wrong.
For supported query syntax, the formatter changes layout and optionally recognized keyword and data-type casing. It preserves identifiers, literals, and comments, but you must still review a semantic diff and test the query because vendor grammar, comments, generated SQL, and application boundaries can make whitespace observable.
No. Stored procedures, stored functions, triggers, and scripts using a custom DELIMITER are outside this tool's contract. Use the database vendor's formatter, parser, or IDE and run the script in an isolated test database.
The exact limit is 1,000,000 UTF-8 bytes, 20,000 lines, and 100,000 UTF-8 bytes on any one line. Manual mode is the default so an unfinished query is not reparsed on every edit. Split larger files or use a pinned command-line formatter.
Formatting, copy, and download occur in the current browser. Operational analytics can record the selected mode, dialect, byte counts, duration, and stable error class, but not the SQL text. Still remove secrets and regulated data before pasting into any browser session.
Keep the original and formatter settings, compare a semantic diff, run the query against the correct database version and schema with safe data, review EXPLAIN when performance matters, and execute application, migration, permission, and rollback tests before deployment.
Maintained and tested by SimpleWebUtilsReviewed
Method: This check paired the exact “Format a grouped query, then verify it against the review schema” input with SQL Formatter. We followed “Identify the target database, version, and execution context”, captured the result after “Format manually with explicit, reproducible settings”, and compared it with the example while treating “Using the generic dialect for vendor syntax” and “Removing syntax to satisfy the formatter” as explicit boundary questions.
Expected result: The formatter exposed the JOIN predicate, active filter, grouping, and descending alias order on separate reviewable clauses without changing string literals or query structure.
Open the tested workflowUse these focused guides when you need a practical workflow before opening the tool.
Continue with another maintained workflow
Format, minify, and syntax-check eight code and data languages locally with parser-specific engines.
Compare bounded text locally with exact line hunks, code-point highlights, and unified patch export.
Beautify or minify strict JSON locally while preserving duplicate keys and number text.
Convert JSON and YAML locally with strict syntax, loss checks, and bounded YAML feature handling.
Replace literal or regex matches with Unicode boundaries, capture tokens, exact counts, and Worker limits.