SQL Syntax Checker

What the checker catches

The checker reads your SQL with a tokenizer that knows each dialect’s quoting and comment rules, then runs the sql-formatter parser over the result. Together they catch the errors that usually come from copy-paste and string building:

• Unterminated strings: WHERE city = 'Singapore AND vip = true. The message points to the opening quote and reminds you that a quote inside a string is doubled ('O''Brien'), or escaped with a backslash in MySQL.
• Unbalanced brackets: an opening ( that is never closed, a stray ), or a ] where a ) was expected. The position of the unmatched bracket is reported, not the end of the file.
• Unclosed block comments: a /* without */ silently comments out the rest of a script.
• Statements cut off mid-clause: a script that ends with DELETE FROM orders WHERE is reported as “The statement ends with “WHERE” but nothing follows it”. Run as-is, that kind of truncated statement is at best an error and at worst a different query.
• Syntax from the wrong dialect: backtick identifiers checked as PostgreSQL, or [bracketed] names checked as Standard SQL. These come back as warnings that name both the syntax and the dialect, such as “Backtick-quoted names like id are not PostgreSQL syntax”, with a hint listing the dialects that do accept it. Text the parser cannot read at all is a hard error instead.

Pick the right dialect

The Dialect option decides what counts as valid. Standard SQL is strict; choose MySQL, PostgreSQL, T-SQL (SQL Server), PL/SQL (Oracle), SQLite, MariaDB, BigQuery, Snowflake, Amazon Redshift, Spark SQL, Trino / Presto or IBM DB2 to match your database. The same query can flip from valid to invalid: 'O\'Brien' is a complete string in MySQL, while PostgreSQL reads the backslash literally and reports the string as unterminated. Common placeholders such as $1, :since and @customerId are accepted. Dialect-specific quoting is understood as well: PostgreSQL dollar-quoted bodies ($tag$ it's fine $tag$) can contain unescaped quotes, and BigQuery accepts table paths with dashes when they are wrapped in backticks, as in a project named my-project.

Errors appear as you type, with the line and column highlighted in the editor and a one-line hint. The formatted query from the last successful check stays in the output pane, dimmed, so a half-typed edit does not wipe your view.

Limits worth knowing

This is a syntax checker that runs without a database, so it cannot know your schema. A misspelled table or column name, a missing GROUP BY column, a type mismatch or a permission problem will only show up when the query runs. The parser is also forgiving in places: a dangling comma as in SELECT id, FROM users is not rejected, and a misspelled keyword such as SELEC can be read as an identifier. Treat a pass as “no broken quotes, brackets or foreign syntax”, then run EXPLAIN against a real database for anything that matters.

Queries often contain customer data or credentials in connection strings. Checking happens in the browser and nothing is uploaded, so production SQL is safe to paste.

Examples

SELECT id, name, email
FROM customers
WHERE city = 'Singapore AND vip = true
ORDER BY name;

Line 3, column 14: This string is never closed — the ' has no matching '

SELECT o.id, SUM(i.qty * i.price AS total
FROM orders o
JOIN order_items i ON i.order_id = o.id
GROUP BY o.id;

Line 1, column 17: This '(' is never closed

DELETE FROM sessions
WHERE

Line 2, column 1: The statement ends with "WHERE" but nothing follows it

SELECT `id`, `email` FROM `users` WHERE `active` = 1;

SELECT
  `id`,
  `email`
FROM
  `users`
WHERE
  `active` = 1;

Common errors and how to fix them

Related tools

• SQL formatter
• sql minifier
• sql formatter/postgresql
• sql formatter/mysql
• sql formatter/transactsql
• CSV to SQL
• sql style guide