Four data models compared: why JSON, YAML, TOML and XML never map 1:1

The config that would not round-trip — a file converted through three formats and the fields that came back different

An ordinary object containing safe numbers, strings, booleans, arrays and nested objects can survive JSON-to-YAML-to-JSON and JSON-to-TOML-to-JSON tests. Add a null before TOML, a datetime from TOML, mixed XML content or a YAML comment, and some value or source information changes.

The useful question is not whether conversion is universally lossy. It is which input class and which direction preserve the properties you need. ToolAcre’s warnings and refusals make that matrix observable rather than reducing every pair to one marketing promise.

A representative config can round-trip through some pairs, but not every supported shape

JSON provides null, booleans, numbers, strings, arrays and objects in this parser. It has no comments, datetime type or shared-reference syntax. JavaScript parses numbers as IEEE-754 doubles, so an already-unquoted integer beyond the safe range may lose precision before another writer sees it.

Object keys are strings, and optional sorting changes their presentation. Arrays remain ordered. Strict parsing rejects comments, trailing commas and non-finite numeric tokens, establishing a compact baseline for the other readers.

JSON’s value model as used by this JavaScript implementation

ToolAcre accepts YAML through restricted JSON or Core schemas. Anchors and aliases resolve, comments disappear, streams become arrays, duplicate keys keep the last value with a warning, and recursive or explosive aliases are refused.

Custom tags, binary, timestamp, set and language-object constructors are rejected. Core Infinity and NaN become null in target formats with warnings. This is intentionally a subset of YAML’s broader tag system, not a claim of complete YAML object support.

The restricted YAML model ToolAcre accepts

TOML begins with a table and supports strings, signed integers, floats, booleans, arrays, tables and four temporal kinds. It has no null. ToolAcre converts dates and times to source-oriented strings and wide integers to decimal strings rather than losing digits.

When writing TOML, null object keys are omitted and null array entries become empty strings. Root arrays and scalars are refused. Comments and the author’s choice among headers, dotted keys and inline tables do not return through a plain value.

TOML’s root table, temporal values and null boundary

XML is projected as a tree with `@` attributes, ordinary child keys, `#text`, `#cdata`, repeated-sibling arrays and literal namespace prefixes. Comments, declaration and processing instructions are dropped. Mixed-text position is lost, and one versus many cannot be known before repetitions appear.

Values read as strings unless inference is selected. Null written from JSON becomes an empty element and cannot be distinguished from empty string on return. Every DOCTYPE is refused, and invalid names stop serialization instead of being rewritten.

ToolAcre’s XML projection: elements, attributes, text and literal prefixes

Nine directions ship: JSON to YAML, XML, TOML and CSV; YAML to JSON and TOML; TOML to JSON and YAML; XML to JSON. JSON-shaped ordinary values fare best between JSON and YAML. TOML introduces date and null boundaries. XML requires naming and node-category conventions.

CSV is a flat outlier and output only. Arrays or selected objects become rows, nested paths flatten into dotted columns, null merges with empty text and formula-like strings are neutralized. CSV-to-JSON, XML-to-TOML and other absent pairs are refused rather than inferred.

Compatibility matrix for the nine shipped directions, with CSV only as output

Binary formats and schema languages are outside scope. A schema can restore list cardinality or validate business shapes, while binary encodings introduce byte-level types and framing not represented here. The converter never claims those capabilities.

Nor does syntax conversion prove application validity. A clean Kubernetes-shaped YAML, XML order message or TOML project file can still violate the target contract. Use the domain validator after inspecting the syntax mapping.

Takeaway: pick the model, then the syntax — and how the Syntax converters panel lets you test a conversion before committing to it

Choose the data model before choosing its punctuation. If comments and aliases matter, a JSON hop cannot preserve them. If null matters, TOML output changes it. If ordered mixed content matters, a plain JSON projection is insufficient. If the destination is a table, nested JSON requires an explicit flattening convention.

Use ToolAcre to test one representative document and read every warning. The result is evidence about a concrete pair and input, not permission to call all conversions lossless or every supported parser complete.

Build the representative document from the boundaries that matter to your service: null, empty text, a large identifier, a date-like string, one repeated record, a comment or alias if YAML is involved, and mixed text if XML is involved. Compare normalized values after each supported hop and retain warnings with the result. That matrix becomes a decision artifact for the chosen model rather than a vague preference for a familiar syntax.