How conversion works

Every conversion goes through JSON. The source is parsed into a JSON value, then that value is written out in the target format. Two consequences follow. First, anything the source format has that JSON lacks, such as YAML comments, XML namespaces, or Protobuf field numbers, is gone by the time the output is written. Second, a target can only express what it supports: CSV needs flat rows, TOML needs a table at the top, and XML needs a single root element.

Conversions run in your browser, so the data is not uploaded. For scripts and pipelines, the same conversions are available through the conversion API. Each pair page below shows a sample converted by the same code at build time, with the input and output sizes, so you can see what the output looks like before pasting your own data.

Choosing a target format

Sending data to an LLM: use TOON. It uses about 40% fewer tokens than JSON on average (39.9% in the official TOON benchmark), from ~22% on mixed/nested structures to ~59% on uniform tables.

Querying, validating, or streaming compact files: use TONL, which pairs a compact encoding with a query API and schema validation.

Feeding code or an API: convert to JSON. It is the only target every language parses out of the box.

Opening in a spreadsheet: convert to CSV, but only if the data is a list of flat records.

Writing configuration: YAML for Kubernetes, CI, and Docker Compose; TOML for Python and Rust project files.

Integrating with legacy or schema-first systems: XML for SOAP and feeds, Protobuf text format when you already have a .proto schema.

When TOON helps and when it does not

TOON writes the field names of a uniform array once, as a header, and then one row per record. That is why CSV to TOON, SQL results, log events, and API lists of similar objects compress well. Configuration files, single deeply nested objects, and records whose keys vary have no shared header to factor out, so TOON writes them as indented key: value lines and the savings over minified JSON are much smaller. YAML to TOON is a good example: a typical service config comes out about the same size. Read when not to use TOON before converting everything by default.

Pairs with caveats

Into CSV: the data must be a root-level array of flat objects. TOML, XML, and Protobuf documents always parse to an object, so convert them to JSON first and extract the array.

From CSV: CSV has no types, so every number arrives as a string. Fix types in JSON before converting onward if they matter.

From XML: attributes become keys prefixed with @_, and a lone child element becomes an object rather than a one-item array.

Into TOML: a root array is wrapped as [[data]], and null values are dropped because TOML has no null.

Into Protobuf: output is text format. Encoding it as binary needs a .proto schema with matching field names and types.

JSON

Use JSON when you need maximum compatibility with other systems, APIs, or programming languages. It's the de facto standard for web APIs and data exchange.

View docs

JSON → TOON JSON → TONL JSON → YAML JSON → TOML JSON → CSV JSON → XML JSON → Protobuf

TOON

Use TOON when building LLM-powered applications, optimizing API costs, or when you need compact, readable data for AI models.

View docs

TOON → JSON TOON → TONL TOON → YAML TOON → TOML TOON → CSV TOON → XML TOON → Protobuf

TONL

Use TONL when you want a compact text format plus tooling around it: querying, schema validation, or streaming. For plain prompt compression, TOON is usually the simpler choice.

View docs

TONL → JSON TONL → TOON TONL → YAML TONL → TOML TONL → CSV TONL → XML TONL → Protobuf

YAML

Use YAML for configuration files, especially in DevOps (Docker, Kubernetes, GitHub Actions). It's more readable than JSON but can have ambiguity with indentation.

View docs