How to use the sql compare
- Paste your first SQL statement into the First SQL statement box.
- Paste the second statement into the Second SQL statement box.
- The tool automatically normalises both inputs by uppercasing keywords, removing comments and collapsing whitespace.
- Read the result to see whether the statements are textually equal, and review the line-by-line diff for any differences.
How the normalisation works
The sql compare process starts by tokenising each input. The hand-written scanner recognises single-quoted strings (with doubled quotes like 'it''s'), double-quoted identifiers, numbers, operators, block comments (/* ... */), line comments (-- ...) and plain words. After scanning, all comments are discarded. Remaining tokens are joined with single spaces, and every alphabetic word outside of string literals or quoted identifiers is converted to uppercase. For example, select id from users where name = 'alice' becomes SELECT ID FROM USERS WHERE NAME = 'alice'. The two normalised strings are then compared character by character.
Textual comparison, not semantic equivalence
This tool performs a strict textual comparison. It does not parse SQL grammar, resolve column aliases, expand wildcards or evaluate expressions. Two queries that return identical result sets can still be flagged as different if their syntax varies. For instance, SELECT a, b FROM t and SELECT b, a FROM t produce different row layouts but might be considered equivalent in some contexts. This tool will correctly report them as different because the token order differs. If you need to verify that two queries return the same data, run them against a database and compare the outputs instead.
Reading the diff output
When the normalised statements differ, the tool splits each one at semicolons and compares corresponding lines. Each line in the diff is prefixed with a marker:
- Space: the line appears identically in both statements.
- Minus (-): the line exists only in the first statement.
- Plus (+): the line exists only in the second statement.
This format mirrors standard unified diffs, making it easy to spot exactly which clauses or values changed between the two versions.
Tokenizer limits and dialect support
The tokenizer is intentionally simple and dialect-agnostic. It handles standard single-quoted strings with escaped quotes via doubling, double-quoted identifiers, basic numeric literals including decimals, and common operators. However, it does not fully support every vendor extension. Backtick-quoted MySQL names and PostgreSQL dollar-quoted strings are kept as single tokens. Bracket-quoted T-SQL names and Unicode escape sequences inside strings are not specially handled. For most day-to-day sql compare tasks involving standard DML and DDL, the normaliser works reliably. If you use heavily dialect-specific syntax, verify the normalised output visually before trusting the equality result.
Common use cases
Developers frequently need to compare SQL during code reviews, migrations and debugging. You might receive a formatted query from an ORM and want to check it against a hand-written version. Or you may have minified a query using a tool like sql minify and need to confirm the minified form matches the original. When generating bulk inserts from CSV data with csv to sql insert, comparing the output against an expected template ensures correctness. Similarly, after converting results with sql to json or sql to csv, you can verify the source query has not drifted from the documented version.
Reference: normalisation examples
| Original input | Normalised output |
|---|---|
select 1 | SELECT 1 |
SELECT /* c */ a FROM t | SELECT A FROM T |
SELECT 'it''s ok' | SELECT 'IT''S OK' |
select "My Col" from t | SELECT "My Col" FROM T |
SELECT 1; SELECT 2 | SELECT 1 ; SELECT 2 |
Note that string literal contents are preserved exactly as typed, including their original case, while unquoted identifiers and keywords are uppercased.
Worked examples
| Example | Input | Result |
|---|---|---|
| Same query, different formatting | First SQL statement: SELECT id, name FROM users WHERE active = 1;; Second SQL statement: select id,name / from users / where active=1; | Equal: Yes; First normalised length: 46 chars; Second normalised length: 46 chars |
| Comments removed | First SQL statement: SELECT /* columns */ id FROM users;; Second SQL statement: SELECT id FROM users; | Equal: Yes; First normalised length: 22 chars; Second normalised length: 22 chars |
| Different string literals | First SQL statement: SELECT * FROM t WHERE name = 'Alice';; Second SQL statement: SELECT * FROM t WHERE name = 'Bob'; | Equal: No; First normalised length: 38 chars; Second normalised length: 36 chars |
FAQ
Does this tool execute my SQL?
No. The sql compare tool only reads your input as text, tokenises it and normalises the tokens. Nothing is sent to a database or any server.
Why do two queries that return the same data show as different?
This is a textual comparison, not a semantic one. Differences in column order, alias names, join syntax or implicit versus explicit casts will cause the normalised strings to differ even if the result sets match.
Are comments really ignored?
Yes. Both block comments and line comments starting with two hyphens are stripped during tokenisation before the comparison happens.
Does it handle stored procedures or multiple statements?
It tokenises everything you paste as a single stream. Multiple statements separated by semicolons are supported, and the diff splits on semicolons for readability. Complex procedural blocks work as long as the tokenizer can scan the characters.
Is my data private?
All processing happens locally in your browser. Your SQL statements are never uploaded anywhere.
What about backticks or square brackets for identifiers?
Backtick and double-quoted names are kept as single tokens with their original case. Square brackets are not special. For best results, stick to standard quoting or be aware that vendor-specific quoting may affect the normalised output.