SQL conversion is the process of extracting data from a SQL script and reorganizing it into other data formats such as JSON, CSV, XML, YAML, HTML and Markdown. SQL (Structured Query Language) is the standard query language for relational databases, and database export tools (such as mysqldump and pg_dump) typically export data as INSERT statements in a SQL script. While this format is convenient for database imports, it is not convenient for programs to read, for data analysis or for cross-system exchange—so it often needs to be converted into more universal formats.
A typical SQL data export script contains two kinds of statements: CREATE TABLE defines the table structure (column names, data types, constraints), and INSERT INTO ... VALUES (...) inserts the actual data. This tool parses both kinds of statements—extracting column definitions and type information from CREATE TABLE and actual data rows from INSERT—and then reorganizes them according to the format you choose. The entire parsing process runs locally in your browser and does not depend on any back-end service.
Why convert SQL into other formats? Although SQL is universal, it is inconvenient in these scenarios: first, front-end programs find it far easier to read JSON than to parse SQL, with no need for a SQL parser; second, spreadsheet tools such as Excel and Google Sheets natively support CSV rather than SQL; third, in configuration-file and documentation contexts YAML and Markdown are more readable than SQL; fourth, cross-system data exchange often uses XML or JSON as a neutral format. Converting SQL into these universal formats lets the data be consumed directly by more tools and languages.
The SQL parser in this tool is hand-written and focused on INSERT and CREATE TABLE statements. For INSERT, it supports both single-value tuples (INSERT INTO t (a,b) VALUES (1,2)) and multi-value tuples (INSERT INTO t (a,b) VALUES (1,2), (3,4), (5,6)), automatically mapping data by column name. For CREATE TABLE, it parses column definitions, data types (VARCHAR(255), INT, DECIMAL(10,2) with parenthesized lengths), NOT NULL, PRIMARY KEY, IF NOT EXISTS and other constraints and clauses, correctly handling nested parentheses to avoid incorrect splitting.
Type recognition is the key to SQL conversion. The tool automatically infers the type from the literal form of a value: anything wrapped in single or double quotes is a string; NULL (case-insensitive) is the null value; TRUE/FALSE is a boolean; 0x..., X'...', B'...' are hexadecimal literals; and a pure number (with optional sign, decimal point or scientific notation) is a number. This automatic type recognition ensures that converted JSON, CSV and other formats preserve the original data semantics (the number 1 is not the string "1"), so downstream programs can handle it correctly.
Differences in quoting styles between database dialects are a common pitfall in SQL parsing. MySQL wraps identifiers (table names, column names) in backticks (`), PostgreSQL uses double quotes ("), SQL Server/T-SQL uses brackets ([]), and standard SQL also uses double quotes. The tool's unquoteIdentifier function automatically recognizes and strips these quotes and handles escapes inside them (`` → `, "" → "). In SQL rebuild mode, INSERT statements can be regenerated with the quote style of the target dialect.
SQL string escaping is another key technical point. The SQL standard escapes a single quote inside a string by doubling it ('It''s' represents It's), while MySQL also supports backslash escaping (\n, \t, \', \", \\, \0, \Z, etc.). The tool's string parser handles both escape mechanisms to correctly restore the original string content. When converting to CSV, fields containing commas, quotes or newlines are re-escaped per RFC 4180; when converting to XML/HTML, special characters such as &, <, >, " and ' are escaped.
Pure front-end processing is the core design principle of this tool. All SQL parsing and data conversion run in your browser's JavaScript engine, and no data is sent to any server. This means that even if your SQL script contains user privacy, commercially sensitive information or internal database structures, nothing leaks externally. This design is particularly suitable for processing production database exports, with no data-compliance concerns. Front-end processing also has no network latency, so conversion speed is limited only by your device's CPU and memory.
Compared with traditional command-line SQL conversion tools (such as sql2csv and sqlparser), this tool has several advantages: no installation or environment configuration is required—just open the page and start using it; it provides a visual interface with a real-time preview of the conversion result; it supports multiple output formats that switch with one click; it ships with sample data and built-in help; and its mobile-responsive design lets you use it anywhere. In exchange, the tool focuses on data extraction and does not handle complex dialect differences (such as PostgreSQL's JSONB operators or MySQL's ON DUPLICATE KEY UPDATE) or advanced features (stored procedures, functions, triggers). For such needs, use native database tools or a dedicated ETL platform.
When using a SQL conversion tool, a few best practices are worth noting: first, before converting, check that your SQL script contains actual data (INSERT statements) rather than only queries (SELECT)—SELECT is not parsed; second, for scripts with multiple tables, enable "Output tables separately" to preserve table structure information; third, when processing SQL that contains Chinese, enable "Include BOM" in CSV output to ensure Excel recognizes the encoding; fourth, when processing large SQL dumps, turn off "Pretty-print output" to reduce output size; fifth, when migrating across databases, use "SQL rebuild" mode to switch dialects, but complex types (such as PostgreSQL arrays and JSONB) may need manual adjustment.
