Cookies for analytics and advertising
We use cookies for analytics and advertising, both sent to Google. Refusing changes nothing you can see.Read the privacy page
Tables and configuration files move between formats constantly and the conversion is usually trivial — which is exactly why it is not worth sending your data to a stranger to have it done. Everything here runs in your browser, so an export full of customer records or a config file with credentials in it never leaves your machine.
Up to 100 files at once. Mixed formats are fine.
They convert one after another and download together as a ZIP.
10 formats in this category, 71 working conversions — 70 of them without your file leaving the device.
The data format of the web. Nested structures, read by every programming language.
One JSON object per line. What log pipelines and data exports stream.
A table as plain text. Every spreadsheet, database and analytics tool reads it.
Like CSV but tab separated, which avoids the comma-inside-a-field problem entirely.
Columnar storage for large datasets. Far smaller and faster to query than CSV.
The verbose ancestor of JSON. Still the backbone of enterprise and government data exchange.
Indentation-based configuration format. Readable by people, picky about whitespace.
A configuration format that stays readable without YAML’s indentation traps.
Sections and key-value pairs. The oldest configuration format still in daily use.
A table rewritten as INSERT statements, ready to load straight into a database.
Read only — we can open this format but not write it.
Somebody verifying that a download arrived intact and unmodified, usually comparing against a hash published on the project page they downloaded it from.
CSV looks simple and is not. There is no single standard: separators differ by locale, quoting rules vary, and a field containing a comma or a newline is where most naive converters break. Numbers are the other trap — an identifier with leading zeros or a long number will be silently mangled by anything that guesses types too eagerly.
The structural mismatch matters more. JSON and YAML nest arbitrarily; CSV is flat. Converting a nested document to a table means deciding how to flatten it, and converting the other way means deciding what the columns become. There is no single right answer, which is why the pages say what they chose rather than pretending the question does not exist.
Parquet is columnar and compressed, which makes it dramatically smaller and faster to query than the same data as CSV — often by an order of magnitude on anything large. It is the right format for data you will analyse repeatedly, and the wrong one for data a colleague needs to open in a spreadsheet.
Reading and writing it happens in your browser like everything else in this category, which for a dataset of any size is also simply faster than uploading it would be.
No, and in this category that is often the whole reason to use it. Exports contain customer records, config files contain credentials, and neither should be pasted into a website. Everything here runs in your browser and nothing is transmitted.
That is the single most common way data conversion goes wrong, and it is why the pages state how types are handled rather than guessing eagerly. Where a value is ambiguous, preserving what you gave us is the priority.
By flattening, and the pages say how. There is no single correct answer to what a nested document should look like as columns, so the choice is stated rather than hidden.
None that we impose. Because it runs locally the limit is your own memory rather than an upload cap, which for most files means there is effectively no limit at all.