JSON / CSV / YAML / SQL / XML Converter

No. The data is parsed and converted in your browser with JavaScript, and the tool does not upload it to LeedyBox or save it. When the page opens, it loads two open-source libraries from leedybox.com itself, js-yaml for YAML and PapaParse for CSV; they run inside the page, and your data is not sent anywhere.

Input that starts with { or [ is read as JSON, input that starts with < as XML, and input that starts with an SQL keyword such as INSERT, CREATE, SET, START, UPDATE or WITH followed by a space, or with a -- or /* comment, as SQL. Anything else is tried as CSV when its first line contains a comma, tab or semicolon, and then as YAML. Choose the format in the "Input" menu yourself when CSV or YAML starts with a word that is also an SQL keyword, for example a CSV header row that begins with Start date or Update time, because it is then read as SQL and fails; when every line of YAML input has the same number of commas, such as title: Hello, world followed by tags: news, tech, because it can then be read as CSV; for pipe-delimited or single-column CSV, which auto detection does not recognise; and when YAML or CSV input fails, because auto detection then only reports that the format was not recognised, while a chosen format shows the parser's own error and, in most cases, where it occurred.

With the "Input" menu set to JSON, only valid JSON is accepted, so use that setting with "Validate syntax" to check that the text is valid JSON. With "Auto detect", input that starts with { or [ but is not valid JSON is read as YAML flow syntax when possible, and a note says so: trailing commas, single quotes and unquoted keys then work, but an unquoted key needs a space after its colon, because {a:1} is read as a key named a:1 with a null value. // and /* */ comments are not comments in YAML; they can end up inside keys or values, or stop the input from being read, so remove them first. JSON Lines (NDJSON) is offered as an output format but is not read as input when it has more than one line; put the lines between [ and ] with a comma after each line except the last.

Unquoted YAML values that look like numbers are read as numbers, so a version such as 1.10 becomes 1.1, a postcode such as 01234 becomes 1234, and 0x1F becomes 31; put such values in quotes in the YAML to keep them as text. The converter reads YAML with the js-yaml core schema, which follows YAML 1.2 for booleans and dates, so yes, no, on, off and dates such as 2026-10-02 stay text, and only forms of true and false, such as True or FALSE, become booleans. When JSON is converted to YAML, strings that could be misread, such as "01234", "1.10" or "yes", are written in quotes.

Child elements that repeat under the same parent become an array, but a single one becomes a plain value or object, so <items> with one <item> gives a different structure from <items> with two. Every XML value is read as text, so <id>1</id> becomes "1" and 007 keeps its zeros, while comments and processing instructions are dropped. For CSV and SQL output, rows are taken from an array inside single-key wrappers such as <items>, so with only one <item> the whole element ends up as JSON text in a single column; for CSV, "Flatten (a.b.c columns)" splits it into columns.

Yes, as long as the rows are in INSERT INTO ... VALUES statements. CREATE TABLE, SET, LOCK and similar setup statements are skipped, other statements such as DROP TABLE are ignored with a note, and rows from several tables are merged into one list, so paste one table at a time if their columns differ. mysqldump leaves out column names by default, so the columns are named column1, column2 and so on unless you dump with --complete-insert. pg_dump writes rows as COPY blocks by default, which the tool does not read, so dump with --column-inserts instead. If the dump also contains functions or stored procedures, paste only the INSERT statements: the tool splits the input at semicolons, so an INSERT inside a function body can be read as data or stop the conversion.

Every CSV value is treated as text, which keeps leading zeros such as 01234 but turns 42 into "42" in JSON and '42' in SQL, and an empty cell becomes an empty string rather than null or NULL. Each column type is chosen from the values in that column, so a table made from CSV gets text columns: VARCHAR(255), or TEXT when a value is longer than 255 characters (NVARCHAR(255) or NVARCHAR(MAX) for SQL Server, TEXT for SQLite). When the input is JSON or YAML and every value in a column is an unquoted number, or every value is true or false, the column gets a number or boolean type instead: an integer type (INT, INTEGER or BIGINT, depending on the database and the size of the numbers), a floating-point type for decimals, or BOOLEAN (BIT for SQL Server, INTEGER for SQLite). The statement has no primary key, indexes or NOT NULL constraints, so add them before you run it if your table needs them.