Every conversion on this site is a lossy translation somewhere, and the useful question is which loss you are accepting. These converters answer that out loud: they name the values a target format cannot represent, let you choose the rule instead of guessing one for you, and never send the payload anywhere.
{ }
Configuration formats
Move between JSON, YAML, and TOML while keeping format semantics visible.
Pick the target by what reads the file next, not by what looks tidiest in an editor. The four common destinations behave very differently once the data stops being flat.
CSV — right when a spreadsheet or a warehouse is next, wrong for anything nested. CSV has one type — text — so nulls, booleans, and numbers all have to be re-derived on the way back.
YAML — right for configuration a person will edit. It keeps comments and anchors that JSON cannot express, and its type inference will happily turn a version string like 1.20 into the number 1.2.
XML — right when a schema-validated contract already exists. It has no native array, so a list becomes repeated elements and the round trip needs a rule about single-element lists.
JSON Lines — right for streaming and append-only logs. Each record stands alone, so a corrupt record costs you one line rather than the whole file.
What breaks when you convert nested data
Nested objects and arrays are where converters silently disagree. Flattening with dot notation turns {"user":{"name":"Ada"}} into a user.name column, which is reversible right up until a key legitimately contains a dot. Arrays are worse: joining ["a","b"] into one cell is reversible only if the separator never appears inside a value, and giving each element its own column changes the column set whenever the array length changes. The converters here expose the choice, and the JSON to CSV workbench can run the conversion in both directions and diff the result so you can see exactly what changed.
Numbers, precision, and IDs
JSON numbers are IEEE-754 doubles, so anything above 2^53 stops being exact. That is why a snowflake ID pasted through a naive converter comes back with a different last digit. Wherever a converter here has to decide, it keeps the string form rather than silently changing the value — the DynamoDB converter does the same thing, which is why DynamoDB stores its own numbers as strings in the first place.