SQL Converter
Convert SQL between five dialects.
About SQL Converter
SQL Converter rewrites a statement or a whole script from one database dialect to another. Paste the SQL, pick the source and target from Oracle, SQL Server, MySQL, PostgreSQL, and SQLite, and click Convert: the tool maps column types like VARCHAR2 and NVARCHAR, functions like NVL, ISNULL, and DECODE, row limits like TOP and ROWNUM, string concatenation, sequences, IDENTITY columns, and date functions to the target's equivalents, and lists every change it made under the result. Conversion runs entirely in your browser, so schema and queries stay private, and Swap direction runs the result back the other way for a quick sanity check.
How to Use SQL Converter
Paste your SQL
Put a CREATE TABLE, SELECT, INSERT, or a whole script into the left panel. Sample loads a typical Oracle schema plus query to try it with.
Pick source and target
Choose the dialect the SQL is written in and the one you need. All twenty direction combinations across the five databases work.
Convert
Click Convert. The rewritten SQL appears on the right, and the note line lists what was changed: types, functions, row limits, sequences, identity columns.
Copy or download
Click Copy for the clipboard or Download to save it as a .sql file. Swap direction converts the result back for a quick sanity check.
Why Use SQL Converter: Common Use Cases
Migrating an application to a new database
The schema and the queries move first: types, functions, and row limits are the three areas where dialects disagree, and all three are covered.
Running an example written for another database
A tutorial query written for SQL Server or Oracle becomes runnable on your PostgreSQL or MySQL instance in one paste.
Porting stored report queries
Analytics SQL full of NVL, DECODE, and TOP becomes plain COALESCE, CASE, and LIMIT that the whole team can read.
Learning dialect differences
The change notes under the result name every transformation, which is the fastest way to learn what actually differs between two databases.
SQL Converter Specifications
| Input Formats | SQL text |
|---|---|
| Output Formats | SQL text |
| File Size Limit | No strict limit (dependent on device memory) |
| Processing Engine | 100% Client-side (Runs locally in your browser) |
| Data Retention | Files never leave your device |
| Batch Processing | Single file processing |
Tips for SQL Converter
Run the result on a scratch schema before production: no converter, ours included, replaces testing.
Complex procedural code (stored procedures, packages, triggers) needs manual review; the rules focus on types, functions, and query clauses.
Format long results with SQL Formatter before pasting them into a review or a pull request.
Also moving the data, not just the schema? Convert the query, then use CSV JSON when the export lands as CSV between systems.
Convert both ways: Oracle to PostgreSQL, then Swap direction back, and compare with your original to spot anything the rules missed.
Dates with custom format masks are converted for common patterns; exotic masks should be checked by hand.
Frequently Asked Questions
Which databases are supported?
Oracle, SQL Server, MySQL (including MariaDB), PostgreSQL, and SQLite, in every direction. The rule engine normalizes the source dialect and re-emits it for the target, so all twenty combinations share the same quality of rules.
What exactly gets converted?
Column types (VARCHAR2, NVARCHAR, DATETIME, CLOB and friends), common functions (NVL, ISNULL, IFNULL, DECODE, LEN, SUBSTR, INSTR, TO_DATE, TO_CHAR), row limits (TOP, ROWNUM, LIMIT, FETCH FIRST), string concatenation (+ and || and CONCAT), sequences, IDENTITY and AUTO_INCREMENT columns, quoted identifiers, and date functions like SYSDATE and GETDATE().
Does it handle stored procedures and triggers?
Partially. Procedural blocks pass through with their SQL statements converted, but PL/SQL, T-SQL, and MySQL procedure syntax differ far beyond statements, so treat any procedural output as a draft for manual review.
Is my schema uploaded anywhere?
No. The tokenizer and all conversion rules are plain JavaScript running in your browser; nothing is sent to a server, which matters when the SQL contains real table or customer names.
Why does SQL Server string concatenation need a note?
SQL Server overloads + for both numbers and strings. The tool converts + to the standard concatenation operator only when a string literal sits next to it, and says so in the notes, so numeric additions are never touched.
How is this different from SQL Formatter?
The formatter tidies one dialect's layout; this converter changes the dialect itself. They pair well: convert here, then format the result for review.