Moving data between CSV, JSON, YAML, and XML
Data rarely sits still in one format. A report lands as a spreadsheet, an API wants JSON, a deployment pipeline expects YAML, and somewhere in the basement a legacy service still speaks XML. Most of the day-to-day friction in working with data isn't the data itself, it's getting it from the shape you have into the shape something else demands. That's the whole job of a data converter: take structured text in one notation and re-emit it in another, without losing the meaning along the way.
Speedor's converters run entirely in your browser. You paste, you click, you copy the result. Nothing is uploaded, nothing is logged, and nothing leaves your machine. For anyone who's ever hesitated before dropping a customer export into a random website, that local-only design is the point.
What each format is actually good at
It helps to know why these formats exist before you start shuffling between them, because each one was built for a different job.
CSV is the flat, comma-separated grid that spreadsheets love. It's tabular by nature: rows and columns, nothing nested. Open it in Excel, Google Sheets, or Numbers and it just works. The catch is that CSV has no concept of types. The value 007 might be a string, a number, or a zip code, and CSV won't tell you which.
JSON is the lingua franca of the modern web. Almost every API you'll ever call speaks it. JSON handles nesting, arrays, and a handful of real types (strings, numbers, booleans, null), which makes it far more expressive than a flat table. It's compact, machine-friendly, and supported everywhere.
YAML is JSON's more readable cousin. It uses indentation instead of brackets, supports comments, and tends to be the format of choice for configuration files, Docker Compose, Kubernetes manifests, and CI pipelines. When a human has to edit something by hand, YAML is usually kinder on the eyes.
XML is the elder statesman. Verbose, tag-heavy, and still deeply embedded in enterprise systems, SOAP services, financial messaging, and document standards like RSS. You'll meet it less often in greenfield projects, but when you do need it, you really need it.
Where conversions actually happen
The scenarios are pretty concrete once you start looking. Say marketing hands you a spreadsheet of 4,000 contacts and the signup API only accepts a JSON array. You export the sheet to CSV, run it through CSV to JSON, and you've got a payload ready to POST. No glue script, no pandas, no waiting on an engineer.
Or you pull a chunk of JSON back from that same API and you want to drop it into a config file your service reads at startup. Convert it with JSON to YAML and you get something clean and commentable that fits right into your repo. Going the other direction works too when a tool only accepts JSON but your config lives in YAML.
And then there's the integration nobody enjoys: a partner system that only ingests XML. You build your payload in JSON because that's how your app thinks, then convert to XML at the boundary. The shape stays the same, only the syntax changes.
The gotchas worth knowing
Format conversion isn't always lossless, and pretending otherwise leads to bugs. A few things to keep in mind:
CSV forgets types. Because every cell is just text, numbers, booleans, and dates all come out as strings unless the converter guesses for you. If true needs to be a boolean and not the word "true," check the output before you ship it.
YAML cares about whitespace. Indentation isn't cosmetic in YAML, it's structural. One stray space can change which key a value belongs to, and tabs are forbidden outright. After any JSON to YAML round-trip, it's worth a quick eyeball, or run the result back through a JSON formatter to confirm the structure survived.
XML and JSON don't map cleanly. JSON has arrays; XML has repeated elements. JSON has attributes nowhere; XML has them everywhere. Most converters pick a sensible convention, but if your XML uses attributes heavily, the JSON it produces will look a little different from hand-written JSON. That's expected, not a fault.
Nesting depth matters. CSV is flat, so deeply nested JSON can't always collapse into columns without flattening keys (think address.city). Going the other way, a flat CSV becomes a flat array, never a tree.
Why local-only matters here
A lot of data you'll want to convert isn't yours to share. User records, internal configs, API keys buried in a response, financial rows. Plenty of online converters quietly send your paste to a server to do the work. Speedor doesn't. The conversion logic runs in your browser tab, the data never crosses the network, and closing the tab is all the cleanup there is. It's faster too, since there's no upload round-trip, and it works offline once the page has loaded. Free, no signup, no quota.
Frequently asked questions
Is my data uploaded anywhere when I convert it?
No. Every conversion runs locally in your browser using JavaScript. Your data never leaves your device and is never sent to a server, which is why these tools work even when you are offline.
Can I convert CSV to JSON without writing any code?
Yes. Paste your CSV into the converter, click convert, and copy the resulting JSON array. The first row is treated as the column headers, which become the keys for each object.
Why does my converted JSON show numbers as strings?
CSV has no concept of data types, so every value starts as text. Some converters try to detect numbers and booleans automatically, but when in doubt they keep values as strings to avoid corrupting things like zip codes or IDs with leading zeros.
What is the difference between JSON and YAML?
They represent the same kinds of data, but YAML uses indentation instead of braces and brackets, allows comments, and is generally easier for people to read and edit. JSON is more compact and is the default for most web APIs.
Is conversion between these formats always lossless?
Usually, but not always. JSON, YAML, and XML map to each other well in most cases. The trickiest pairings are CSV, which is flat and typeless, and XML, which handles attributes and repeated elements differently from JSON arrays. Always check the output for important data.
Do these converters work on large files?
They handle most everyday files comfortably since the work happens on your own machine. Performance depends on your device rather than a server, so very large files are limited mainly by your browser memory.