{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
The version label fixes the documented grammar baseline used by dialect checks.
Review rules never rewrite the source and do not claim semantic correctness.
Choose Required for migration files or policies that mandate semicolons.
Paste up to 100 KB and 100 statements, or load one local .sql or text file.
{{ sourceMeta }}
{{ fileStatus || 'Drop one SQL or text file onto the editor.' }}
The neutral default keeps source excerpts out of the findings ledger and its exports.
LocationStatementRuleSeverityFindingNext actionCopy
L{{ finding.line }}:C{{ finding.column }}{{ finding.sourceLine }} {{ finding.statement ? `#${finding.statement} ${finding.statementType}` : 'Source' }} {{ finding.rule }} {{ finding.severity }} {{ finding.message }}{{ finding.detail }} {{ finding.action }}
No findings in the selected structural scope.

Showing the first {{ report.finding_count }} findings. Fix them, then validate the updated source to continue.

The chart renderer is unavailable. Exact severity counts remain in the summary and findings ledger.

Boundary
Checked locally

Common DML and DDL statement shapes, CTEs, transactions, comments, quoting, placeholders, delimiters, common clause order, and selected dialect markers.

Requires native validation

Stored procedures, triggers, dynamic SQL, client directives, schema objects, permissions, runtime behavior, result correctness, query plans, and full server acceptance.

Current report
SQL Formatter Format SQL in your browser with dialect-aware layout and an audit that flags fallback output, unbalanced parentheses, and risky reuse.
MySQL Slow Query Log Analyzer Analyze MySQL slow query logs locally to group SQL fingerprints and rank accumulated or tail cost with scan, lock and temp-table findings.
PostgreSQL EXPLAIN Plan Analyzer Inspect PostgreSQL EXPLAIN plans for costly nodes and row-estimate drift with browser-local parsing of scan, spill and buffer clues.
SQLite Manager Open a SQLite file in your browser and inspect schema or rows before running guarded SQL and saving deliberate edits as a new local copy.

SQL shares a familiar vocabulary across database systems, but its grammar is not universal. PostgreSQL accepts the double-colon cast operator, MySQL uses ON DUPLICATE KEY UPDATE, and SQLite supports WITHOUT ROWID. A statement can look reasonable and still be rejected by the database it was written for.

Structural validation checks text before it reaches a database. It can find unclosed strings, mismatched delimiters, missing statement parts, unusual clause order, and selected dialect markers without preparing or executing the SQL. This is useful for reviewing migration fragments, generated statements, examples, and code-review snippets where connecting to a database would be unnecessary or unsafe.

Database acceptance depends on more than syntax. Table and column names must exist, types must be compatible, privileges must allow the operation, constraints must pass, and stored-program bodies may follow their own grammar. Query correctness and performance also require real schema information and often a native parser or query plan.

Execution warning: A clean structural report is not permission to run a destructive statement. Review targets, transactions, backups, permissions, and recovery before executing UPDATE, DELETE, DROP, or TRUNCATE in a real database.

How to Use This Tool:

Choose the intended database first; dialect selection changes quoting, parameters, comments, and accepted syntax markers.

  1. Select PostgreSQL 18.4, MySQL 8.4, or SQLite 3.53.4 as the documented grammar baseline.
  2. Choose Syntax only for structural checks or Syntax + review rules to add warnings for risky or unstable patterns.
  3. Set Statement terminator to required when every statement must end with a semicolon. Optional still treats a top-level semicolon as a statement boundary.
  4. Paste SQL or load one local SQL or text file. Split sources larger than 100 KB, 5,000 lines, or 100 statements into smaller review units.
  5. Read findings in source order. Fix tokenizer and delimiter errors before relying on statement-level messages, because an unclosed quote or bracket can change how later text is grouped.
  6. Run the corrected SQL through the selected database’s native validation or a safe test environment, especially when the report marks a command or procedural body as outside the bounded grammar.

Interpreting Results:

Errors identify source that conflicts with the bounded grammar or selected dialect. Warnings call for review but do not necessarily make the SQL invalid. For example, SELECT * may be intentional, while LIMIT without ORDER BY can still return an unstable subset across plans or runs.

Unsupported means the statement was tokenized and its delimiters were checked, but its full command grammar was not parsed. A zero-finding report therefore means no issue was found inside the stated boundary; it does not claim server acceptance, correct results, good performance, or safe execution.

Technical Details:

The validator is a bounded lexical and structural parser. It normalizes line endings, removes an initial byte-order mark, tokenizes comments, quoted values, identifiers, numbers, parameters, operators, and symbols, then tracks delimiter depth before splitting top-level statements.

Rule Core

  1. Reject null code points, unclosed comments or quoted tokens, mismatched brackets, and nesting deeper than 64 levels.
  2. Split statements only at semicolons outside nested delimiters and enforce the optional or required terminator policy.
  3. Resolve the main command after an optional WITH clause.
  4. Check common shapes for SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, TRUNCATE, and MERGE, plus transaction commands.
  5. Check common top-level clause order and selected dialect-specific tokens.
  6. When review rules are enabled, add warnings for wildcard projections, unrestricted updates or deletes, destructive commands, unordered limits, and equality comparisons with NULL.
ConstructAccepted profileRejected elsewhere
ILIKE, ::, dollar quotes, and $1 parametersPostgreSQLMySQL and SQLite
AUTO_INCREMENT and ON DUPLICATE KEYMySQLPostgreSQL and SQLite
WITHOUT ROWID and bracket-quoted identifiersSQLitePostgreSQL and MySQL
TOPNone of the threeUse the selected dialect’s documented row-limit syntax.

The clause checker recognizes the common order from FROM through RETURNING. It does not model every legal vendor extension or every position in which a keyword may appear, so native validation remains authoritative for production SQL.

Validation Boundary:

Checked locallyRequires the target database
Common DML and DDL shapes, common table expressions, transactions, comments, quoting, placeholders, delimiter balance, and selected dialect markers.Schema objects, column and function resolution, permissions, data types in context, constraints, generated SQL, and full command acceptance.
Selected warnings for potentially broad, destructive, or unstable statements.Runtime effects, transaction semantics, result correctness, locks, performance, query plans, and recovery behavior.
Up to 100 statements and the first 100 findings.Stored procedures, triggers, client directives, dynamic SQL, and vendor extensions beyond the bounded grammar.

The SQL source stays as inert text in the browser and is never sent, prepared, or executed by this validation path.

References: