How does nested JSON convert to CSV?

A nested object or array inside a JSON record gets written into its CSV cell as a literal JSON string (e.g. {"city":"Lyon"}), not flattened into separate dot-notation columns. This keeps the conversion lossless and predictable, though it means the nested value stays as text in that cell rather than becoming its own columns.

Does YAML preserve the data types JSON has?

Yes — numbers, booleans, null, and nested structures all have native YAML equivalents, so they convert without becoming quoted strings. The one edge case is an unquoted date-looking value, which YAML's own rules read as a date type rather than plain text; this converter normalizes that back to a plain date string instead of an invented timestamp.

What happens to arrays when converting JSON to CSV?

If the top-level JSON value is an array of objects, each object becomes a row and each object's keys become columns (unioned across every row, not just the first). An array nested inside a field, rather than at the top level, is written into its cell as a JSON string, same as a nested object.

If I convert CSV back to JSON, do nested objects come back automatically?

No — a cell holding JSON-string text (from an earlier JSON-to-CSV conversion) comes back as that same string, not automatically re-parsed into a nested object. Nothing is lost, but reinflating it into structured JSON is a separate step you'd do yourself if you need it.

Will converting a CSV with numbers like "007" or long ID strings break them?

No — a numeric-looking cell is only converted to an actual number if turning that number back into text reproduces the original exactly. That check specifically preserves leading zeros ("007" stays "007", not 7) and long numeric IDs that would otherwise lose precision as a JavaScript number.

How to Convert JSON to CSV and YAML

How to Convert JSON to CSV or YAML

Paste your JSON, CSV, or YAML into PixelTools' converter, pick the format you're converting to, and it outputs instantly — no upload, no account, nothing leaves your browser. All three formats convert in any direction: JSON to CSV, JSON to YAML, CSV to YAML, and back. There's no direct CSV-to-YAML code path under the hood — CSV and YAML both route through a parsed JSON value as the intermediate step, then get written back out in the target format. That's invisible to you as a user, but it's why the tool behaves consistently: whatever rule applies to "JSON becoming CSV" also applies to "YAML becoming CSV," because YAML gets parsed into the same intermediate value JSON would produce first. For a one-off conversion this is faster than a CLI tool or writing a script, and it's the same conversion logic either way.

What Happens to Nested Objects and Arrays

PixelTools' converter never flattens a nested object into dot-notation columns (like "user.name", "user.email") the way many JSON-to-CSV tools do. Instead, any value that's itself an object or array gets written into its CSV cell as a literal JSON string — you'll see the raw {"city":"Lyon"} text sitting inside that cell rather than split across new columns. This is a deliberate trade-off: dot-notation flattening is more "spreadsheet-native" at a glance, but it can quietly restructure your schema and makes round-tripping back to the original JSON shape unreliable. Keeping the nested value as JSON text means nothing is silently dropped or guessed at, and if you convert that CSV back to JSON later, the nested data is still there as a string you can re-parse — it just won't automatically reinflate into a nested object on its own. If you need dot-notation columns specifically, this isn't that tool; if you need nothing lost, it is.

Do Numbers, Booleans, and Big IDs Survive the Round Trip

Yes, with one specific fix that matters for real-world data: converting CSV back to JSON only turns a numeric-looking cell into an actual number if converting that number back to a string reproduces the original text exactly. That single check is what stops two common failures other CSV parsers hit — a zip code or order number like "007" silently becoming the number 7 (losing its leading zeros), and a 17+ digit ID from a real export losing precision once it's past JavaScript's safe integer range. Plain "true"/"false" text still becomes a real boolean. JSON's own types (numbers, booleans, null, nested structures) pass straight through to YAML unchanged, since YAML has native equivalents for all of them — the visual format changes, the value and type underneath don't.

What If My JSON Rows Don't All Have the Same Keys

It still works — the CSV gets a column for every key that appears in any row, not just the keys in the first one. That distinction matters because it's a real, documented pitfall in a common CSV library: unparsing a JSON array to CSV without an explicit column list normally infers columns only from the first record, so a key that shows up starting on row 5 (an optional field, a later record with one extra property) gets silently dropped from the entire file, including from the rows that do have it. This converter builds its column list from every row's keys before writing anything, so an optional field that's missing on early records still gets its own column, populated where it exists and left blank where it doesn't.

One YAML-Specific Gotcha: Dates

If your data has an unquoted date-looking value — a YAML field like created: 2024-01-15 with no quotes around it — YAML's own default rules parse that as a native date object, not a string. Converting that straight to JSON with a naive tool often produces something like "2024-01-15T00:00:00.000Z", padding on a timestamp that was never actually there in your source. This converter special-cases that: a YAML date scalar comes out as the plain "2024-01-15" string you'd expect, not a JSON-stringified date object with an invented midnight timestamp. It's a small case, but it's exactly the kind of silent reformatting that breaks a config file or a CI pipeline that expects the original date string back unchanged.

When to Use JSON, CSV, or YAML

Use CSV when the destination is a spreadsheet, a database import, or anything expecting rows and columns — it needs your data to already be a flat list of similar objects (or a single object), since CSV has no native way to represent nesting. Use YAML for anything a human edits by hand and re-reads often — CI pipelines, Kubernetes manifests, app config — because it drops JSON's braces and quotes in favor of indentation, which is easier to scan and diff in a pull request. Use JSON as the default for anything API-facing or programmatic, since it's what nearly every language and library parses natively without a dependency. If you're not sure, converting is free and instant here, so it's easier to try the target format on your actual data than to decide in the abstract.