SQL Validator

Check SQL syntax before you run it

The SQL Validator is a syntax checker for SQL queries and scripts. Paste one statement or a whole migration file, choose your database, and every statement gets its own verdict: valid, or a syntax error with the exact line and column, the tokens the parser expected at that point and a plain-English hint about the likely cause.

It supports MySQL, MariaDB, PostgreSQL, SQL Server (T-SQL), SQLite, Google BigQuery, Amazon Redshift, IBM Db2 and Trino/Presto, using the dialect grammars of the open-source node-sql-parser library (Apache-2.0). Oracle is not offered: the library has no Oracle grammar, and guessing would give you false errors.

Everything runs in your browser. Your queries, and any table names or data inside them, are never uploaded — useful when the SQL comes from a production system or a client project.

How to use the SQL Validator

1. Choose your database in SQL dialect. Quoting rules differ, so the same query can be valid in one dialect and invalid in another.
2. Paste SQL into SQL to check, drop a .sql file on it, or press Load file. Separate statements with semicolons; GO lines (SQL Server) and DELIMITER lines (MySQL) are understood.
3. Press Check SQL. After the first check, results refresh as you type.
4. Read each error: the position, what the parser expected, and the hints underneath. Press Show in editor to jump to the exact spot.
5. Review the Parsed structure table to confirm each statement’s type, tables and columns, and open Syntax tree (JSON) if you need the full parse.

SQL Validator features

Worked example

Check this MySQL script, which contains a classic copy-and-paste slip:

SELECT id, name, email,
FROM customers
WHERE deleted_at = NULL;

The validator reports Syntax error · line 2, column 6: the parser accepted FROM as a fourth column name, then found customers where it expected a comma, FROM or the end of the statement. The hint pinpoints the real cause — a trailing comma at line 1, column 23 before FROM. Remove the comma and the statement becomes valid, but a warning remains: = NULL is never true, so the query would return no rows. Changing it to IS NULL clears the warning.

What each dialect covers

Each dialect has its own grammar. In our tests, SELECT (with joins, subqueries, CASE, window functions and CTEs), INSERT, UPDATE, DELETE, CREATE TABLE, ALTER TABLE and DROP TABLE parse in MySQL, MariaDB, PostgreSQL, SQL Server, SQLite, Redshift and Trino. Known gaps:

• BigQuery expects its own types in DDL (INT64, STRING); INT and VARCHAR in CREATE TABLE are rejected, and CREATE INDEX is not supported.
• Db2 uses FETCH FIRST n ROWS ONLY; LIMIT and CREATE INDEX are not in its grammar.
• SQL Server: the grammar is lenient about LIMIT, which SQL Server itself rejects, so the validator adds a warning when it sees it.
• Stored procedures, functions and triggers (CREATE PROCEDURE … BEGIN … END) are mostly outside every grammar. They are marked “Not checked” rather than reported as errors.

Syntax check, not a database

A syntax checker answers one question: is this text a well-formed statement in that dialect? It cannot know your schema, so a query that selects a column that does not exist, joins on mismatched types or violates a constraint will still pass here and fail on the server. Run it against a development database for that. The parser is also an approximation of each vendor’s grammar — rarely used or very new syntax may be rejected even though your database accepts it.

Once the syntax is right, tidy the layout with the SQL Formatter. If your query returns JSON or CSV, the JSON Formatter and CSV to JSON converter help you inspect the results.