SQL Formatter and Validator
Turn dense SQL into readable, consistently indented text and catch common structural mistakes instantly. Your query stays in this browser and is never executed.
Format SQL in real time
Structural guidance only—your database engine remains the authoritative validator.
Why format SQL before reviewing it?
SQL is easier to understand when its structure is visible. Consistent line breaks separate selected columns, source tables, joins, filters, grouping, ordering, and limits. Indentation exposes nested expressions and subqueries. That visual hierarchy helps reviewers notice an unexpected join, a filter attached to the wrong statement, a missing condition, or a column that was accidentally included.
Formatting does not change what a valid query means when tokens are preserved correctly. It changes presentation. This page tokenises comments, quoted strings, quoted identifiers, words, numbers, operators, commas, semicolons, and parentheses before rebuilding the layout. String contents are not uppercased with keywords, so a value such as 'select from reports' remains data.
How the formatter organises a query
Major clauses such as SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, UNION, and common JOIN forms begin on new lines. Comma-separated SELECT items are split across lines when they are at the top level. Parentheses increase indentation for nested expressions, and closing parentheses reduce it. Semicolons end statements and create a clean boundary before the next statement.
SELECTcustomers.id,
customers.name,
COUNT(orders.id) AS order_count
FROM customers
LEFT JOIN orders ON orders.customer_id = customers.id
GROUP BY customers.id, customers.name;
What the validator checks
The validator reports unmatched parentheses, unfinished quoted strings, unfinished block comments, unexpected closing parentheses, and statements that do not begin with a recognised SQL command. It also provides review warnings for UPDATE or DELETE statements that appear to have no WHERE clause and for SELECT star usage. These warnings are intentionally conservative: there are legitimate reasons to update every row or select all columns, but those choices deserve attention.
This tool does not connect to a schema, so it cannot confirm that tables and columns exist, aliases are unique, types are compatible, permissions are sufficient, or a query plan is efficient. It also cannot fully parse every vendor extension. Run important SQL in the database’s explain, lint, or validation facility using a safe non-production environment.
Dialect selection and limitations
The dialect option records the context and adjusts guidance, but this lightweight formatter does not claim complete grammar coverage for PostgreSQL, MySQL, SQL Server, SQLite, or every version. Vendor-specific procedural blocks, dollar-quoted strings, unusual operators, JSON path syntax, batch separators, and delimiter-changing commands may need a dedicated parser. Preserve a source copy before reformatting complex migration or stored-procedure scripts.
Practical SQL review checklist
- Confirm the target database, schema, and transaction boundary.
- Review every JOIN condition and check whether an outer join is intentional.
- For UPDATE and DELETE, run the WHERE condition as a SELECT first and inspect the affected rows.
- Avoid committing secrets, personal data, production identifiers, or credentials in example queries.
- Use parameterised queries rather than joining untrusted values into SQL strings.
- Inspect an execution plan before running expensive queries on large tables.
Methodology and privacy
Formatting and structural checks are implemented in client-side JavaScript. Input is scanned character by character so quoted text and comments can be separated from keywords. Whitespace is then rebuilt according to clause, comma, and parenthesis rules. Nothing is submitted to a database or MiniUtils endpoint.
Frequently asked questions
Does a green result mean the query is valid?
No. It means the lightweight checks did not find a supported structural issue. Only the intended database version, schema, and permissions can decide whether the query is valid and executable.
Can formatting change a query?
The formatter is designed to preserve tokens, but complex vendor syntax can exceed its simplified rules. Compare important scripts and keep version control or a backup.
Why warn about UPDATE or DELETE without WHERE?
Those statements can intentionally affect every row, but accidental omission is costly. The warning prompts a deliberate review without blocking the output.
Does the tool prevent SQL injection?
No. Formatting is unrelated to safe parameter binding. Use your database driver’s parameterised-query APIs and validate application logic.
Is pasted SQL stored?
No. The page processes it locally. Avoid pasting credentials or confidential production data into any utility on an untrusted device.
References
For grammar and dialect details, consult the official documentation for your database, such as the PostgreSQL SQL language reference, MySQL SQL statements reference, or equivalent documentation for the version you deploy.