Large files & privacy: nothing leaves this tab
Most online CSV converters are upload services with a textarea in front. Your paste — which is often a customer list, a payroll export, or an API dump full of tokens — travels to a server, gets processed there, and lives in someone's logs for an undisclosed amount of time; at least one popular converter has made pasted data publicly reachable by URL. This page is the other architecture: the file API reads your file into the tab's memory, JavaScript parses it there, and the output exists only on your screen until you copy or download it. There is no upload endpoint to send data to. You can load the page, disconnect from the internet, and everything still works.
That design also sets the size ceiling honestly: it's your machine's memory, not a server plan. Multi-megabyte files parse with a progress bar (a background worker keeps the page responsive); files in the tens of megabytes work on typical hardware. Beyond that, browser memory limits apply — if you need to break a giant file down first, that's exactly what our CSV splitter is for.
Type detection you can argue with
Naive converters make every value a string, which means "age": "42" and a second pass of cleanup in your code. Aggressive converters convert everything that looks numeric, which is how ZIP code 00501 becomes the number 501 and a phone number loses its leading zero. This tool takes a middle path with explicit rules:
42and3.14become numbers;true/falsebecome booleans; a literalnullbecomesnull.- Leading-zero protection:
007and00501stay strings — a value that starts with0followed by more digits is an identifier, not a quantity. - Scientific notation stays a string:
1e5is not converted. Values like that are as likely to be a product code or a plate number as a count of 100,000, and turning them into numbers silently is the kind of damage you only notice in production. Force the column to Number if it really is one. - Empty vs null is your call: by default an empty cell becomes
null; untick the toggle to get""instead. They mean different things to most databases and most APIs, so the tool doesn't collapse them for you. - Per-column overrides appear under the output once data is parsed — force any column to Text, Number, or Boolean — and a global keep everything as strings toggle turns inference off entirely.
Nested JSON from dotted and bracketed headers
Flat objects are the default, but CSV headers can describe structure: a header of user.address.city means "put this inside user, inside address". Choose the Nested objects output mode and dotted headers build real nesting, while bracketed headers build arrays — tags[0] and tags[1] become a two-element tags array. This is the round-trip partner of flattening: if you exported nested JSON to a spreadsheet using dotted keys (our JSON utilities page does exactly that), this mode reassembles the original shape.
user.name,user.address.city,tags[0],tags[1]
Ada,Oslo,admin,ops[{"user": {"name": "Ada", "address": {"city": "Oslo"}}, "tags": ["admin", "ops"]}]The other output modes cover the remaining shapes real code wants: JSONL writes one object per line for log pipelines and bulk-import endpoints; keyed object turns a chosen column into the top-level keys (handy for lookup tables — duplicate keys keep the last row and you get a warning); and arrays of arrays is for headerless files where positions, not names, carry the meaning.
JSON to CSV, same page, reverse gear
Switch the direction and paste JSON — an array of objects, a single object, or JSONL — and you get CSV back. Nested keys flatten to dotted headers (user.address.city), arrays inside objects become bracketed headers, and the column set is the union of keys across all objects in first-seen order, so ragged API responses don't lose fields. Output quoting follows RFC 4180: any value containing the delimiter, a quote, or a newline gets wrapped in double quotes, and quotes inside values are doubled. You choose the delimiter (comma, semicolon, tab, pipe), the line ending (CRLF as the spec prescribes, or LF), and whether to prepend a UTF-8 BOM — the three bytes that stop spreadsheet applications from displaying é where é should be.
CSV to SQL INSERT statements
The third output this page generates is SQL: paste or load a CSV, name the target table, and get INSERT statements ready to run. This isn't string concatenation with fingers crossed — the details that break naive generators are handled:
- Quote escaping done correctly: a value like
O'Brienbecomes'O''Brien'— the single quote doubled, per the SQL standard. This is the difference between a working import and a syntax error (or worse) halfway through row 40,000. - Column types, inferred or chosen: each column is sniffed as INTEGER, REAL, or TEXT (leading-zero values sniff as TEXT, same protection as the JSON side), and every column has a dropdown to override. Numeric columns emit unquoted literals; everything else is quoted.
- NULL for empty cells is a toggle — on, an empty cell becomes the keyword
NULL; off, it becomes''. - Batched multi-row INSERTs: one statement per row is slow to execute and noisy to read. Set rows-per-statement and get
INSERT INTO t (a, b) VALUES (…), (…), (…);batches of the size you choose. - Identifier quoting is a three-way choice: none (identifiers sanitized to letters, digits, underscore),
"double quotes"(the SQL standard, used by PostgreSQL and SQLite), or`backticks`(MySQL/MariaDB). The generated DML is otherwise standard SQL and runs unchanged on all of them.
Semicolons, tabs, and the European Excel problem
"CSV" rarely means comma-separated in practice. Spreadsheet software on a system with European regional settings exports with semicolons, because the comma is the decimal separator (3,14) and can't also delimit fields. Database dumps and clipboard pastes are frequently tab-separated; pipe-delimited files turn up in legacy feeds. The delimiter selector defaults to auto-detect — the first rows are sniffed, quoted sections excluded, and the most frequent candidate among comma, semicolon, tab, and pipe wins — with a manual override for the files that fool sniffing, like a single-column file containing addresses full of commas.
CSV quoting rules, in one place
These are the parsing rules this tool implements, paraphrased from the CSV conventions standardized in RFC 4180 — they're also the checklist for debugging a "broken" CSV by hand:
- A field must be quoted (wrapped in double quotes) if it contains the delimiter, a double quote, or a line break. Quoting any other field is allowed but optional.
- A double quote inside a quoted field is escaped by doubling it: the field value
say "hi"is written"say ""hi""". There is no backslash escaping in CSV. - A quoted field may contain real line breaks — one record can span multiple lines of the file. Any splitter or parser that works line-by-line corrupts these files.
- Records end with CRLF per the spec, but bare LF is ubiquitous; both are accepted here and treated identically.
- A trailing delimiter means a trailing empty field —
a,b,is three fields, the last one empty, not two. - Rows with fewer fields than the widest row are padded with empty values and flagged with a warning — never silently dropped. A ragged row usually means an unescaped quote upstream, and hiding it helps nobody.
What this tool doesn't do (on purpose or honestly)
No spreadsheet formula evaluation: a cell containing =SUM(A1:A9) converts as the literal text, because this is a parser, not a spreadsheet engine. No XLSX: Excel workbooks are ZIP archives of XML, a different format entirely — export to CSV first; for cleaning up marketplace CSV exports specifically, see our Shopify CSV cleaner. Character encoding is assumed UTF-8 (a leading BOM is tolerated and stripped); files in legacy encodings like Windows-1252 may show mojibake for accented characters — re-save as UTF-8 and reload. And the parser is strict about structure but forgiving about mess: it will warn about ragged rows and unclosed quotes rather than refusing to work.