JSON, JSONL and TOON: Matching Each Data Format to Its Bottleneck

For years, JSON has been the default way to write down structured data. REST APIs, config files, databases, browser apps and service-to-service traffic all lean on it. Yet the way software handles data keeps shifting. Datasets are huge, events arrive as streams, and Large Language Models now take structured data as input.

Two other formats have been getting attention because of this: JSONL and TOON. They can look like rivals to JSON at first glance, but each answers a different question. JSON is built for exchanging structured data. JSONL is built for working through independent records efficiently. TOON is built to make JSON-shaped data smaller and cheaper in tokens when it's headed to an LLM. Asking which one is "better" misses the point. Understanding what each is for is more useful.

JSON: the general-purpose baseline

JSON, short for JavaScript Object Notation, represents data with objects, arrays, strings, numbers, booleans and null. The syntax isn't its main strength. The ecosystem around it is: nearly every programming language ships a JSON library, and web platforms support it natively.

A typical dataset looks like this:

{
  "users": [
    {
      "id": 1,
      "name": "Alice",
      "role": "admin"
    },
    {
      "id": 2,
      "name": "Bob",
      "role": "user"
    }
  ]
}

That shape suits an app that needs to hand over structured information, which is why JSON fits REST APIs, configuration, application data and any case where the whole structure is a manageable size.

Trouble starts when the same shape is stretched to very large datasets, or when an LLM must read thousands of similar objects.

JSONL: one record per line

JSONL stands for JSON Lines. Rather than wrapping every record inside one big array, it writes a full JSON object on each line. The same users could be stored like this:

{"id":1,"name":"Alice","role":"admin"}
{"id":2,"name":"Bob","role":"user"}
{"id":3,"name":"Carol","role":"user"}

Each line is an independent record. That looks like a minor syntax tweak, yet it changes how the data can be handled. A large JSON array may force a program to parse the entire structure before touching any record. With JSONL, a program reads a line, parses it, processes it and moves on to the next.

The payoff is biggest for log files, event streams, ML training sets, ETL jobs and any other data that's large or keeps growing. Take a 50 GB dataset. Loading all of it as one giant object is rarely what you want. With JSONL, records can be handled incrementally, and memory mostly goes to whatever records are in flight at the moment.

So JSONL answers a data-processing problem.

TOON: fewer tokens for the model

Now picture a different issue: sending thousands of structured records to an LLM. JSON works, but it carries a lot of punctuation and repeated names:

{
  "users": [
    {"id": 1, "name": "Alice", "role": "admin"},
    {"id": 2, "name": "Bob", "role": "user"},
    {"id": 3, "name": "Carol", "role": "user"}
  ]
}

Look at how "id", "name" and "role" repeat in every object. Conventional software doesn't care much. For an LLM, though, all those characters add to the input token count.

That's the gap TOON, or Token-Oriented Object Notation, fills. It's a compact, human-readable encoding of the JSON data model, aimed mainly at prompts and other contexts where token use matters. The same records come out like this:

users[3]{id,name,role}:
  1,Alice,admin
  2,Bob,user
  3,Carol,user

Field names are declared once, and the records then appear as rows. The principle is simple: don't keep telling the model the same structure, state it once and supply the values.

The question each format asks

One way to keep the three apart is to look at what each is trying to solve.

• JSON asks how structured data can be represented in a format that everyone supports.
• JSONL asks how many independent records can be represented so they can be processed a piece at a time.
• TOON asks how JSON-shaped data can be written more compactly when it's sent to an LLM.

That's why JSONL and TOON aren't substitutes for each other. JSONL changes how records are organised. TOON changes how structured data is represented, in the name of token efficiency. JSON stays underneath as the general-purpose format in many of these workflows.

Scenario one: a busy log pipeline

Consider a large log-processing system where thousands of events appear every second:

User logged in
Payment completed
Order created
Email sent

If those events are stored as separate JSON objects, one per line, a consumer can process them as they come in. This is where JSONL works well. It fits data that's large, append-only, continuously produced or naturally made of records, so logs, event streams, ML pipelines, ETL systems and big-data processing are the usual homes for it.

JSON remains the more natural option when the whole structure is one logical document, or when applications expect ordinary JSON APIs.

Scenario two: an agent reading 10,000 customers

Now an AI agent needs information about 10,000 customers. Sent as JSON-style records, every row repeats its keys:

{"id":1,"name":"Alice","city":"Delhi"}
{"id":2,"name":"Bob","city":"Mumbai"}
{"id":3,"name":"Carol","city":"Pune"}

TOON can lay a uniform collection out as a table, with the field names given once:

customers[3]{id,name,city}:
  1,Alice,Delhi
  2,Bob,Mumbai
  3,Carol,Pune

That's where the token savings come from. According to the spec, TOON is an indentation-based, line-by-line encoding of the same data model JSON uses, and each array announces its length and its field list just once.

The project also reports benchmarks where TOON used markedly fewer tokens than formatted JSON on its test datasets. How much you save depends on the data's shape and on the tokenizer, though. TOON isn't automatically better for every dataset. Its biggest gains come with uniform arrays of objects whose fields repeat.

Will TOON replace JSON?

Saying so is tempting and too simple. The specification itself presents TOON mainly as a representation for JSON-shaped data. It says TOON isn't meant to replace JSON in general-purpose APIs, nor in cases with deep nesting or non-uniform structures.

A realistic workflow keeps JSON where it already works and adds TOON only at the model boundary:

Application data
      ↓
    JSON
      ↓
Convert for LLM
      ↓
    TOON
      ↓
     LLM

JSON stays as the application's native representation, and TOON becomes the format used when structured data goes into an LLM. In that role TOON looks more like a translation layer than a universal replacement.

Using them together

The formats can also share one architecture. JSONL concerns how records are organised and processed. TOON concerns how structured data is represented efficiently for an LLM. An application might produce a large stream of records as JSONL, process them incrementally, pick out the relevant subset, and then encode that subset as TOON before sending it to a model.

Each format removes a different bottleneck. JSONL helps with large-scale record processing, TOON with token efficiency, and JSON with general-purpose interoperability.

Picking one

Reach for JSON when you want a widely supported, general-purpose way to hold structured data. Public APIs, browser apps, config files and datasets of modest size are the obvious cases. Few formats match its tooling, and a small conventional dataset gives no reason to bring in anything else.

Consider JSONL when the data is a pile of independent records you want to process incrementally. Logs, event streams, ML training data, ETL pipelines and big datasets are strong examples. The deciding question is whether the whole dataset must be handled as one structure or whether one record at a time will do. If the latter, JSONL is worth a look.

Consider TOON when the consumer is an LLM and the data holds many repeated, structured records. It suits uniform arrays where the same fields recur across many objects, which its specification names as its sweet spot. Deeply nested or highly irregular data may be simpler or smaller as JSON. The question to ask is whether tokens are being wasted describing the same structure again and again. If yes, TOON deserves an evaluation.

Different pressures, different formats

JSON isn't going away. What's happening is that different data problems are producing specialised formats. JSON won because software needed a simple, interoperable way to describe structured data. JSONL grew out of the need to work with independent records, particularly as datasets got bigger or arrived without pause. TOON comes from another pressure: LLMs work in tokens, and sending structural syntax over and over costs something.

So the right mental model isn't a chain that ends with JSON dead. It's this: JSON for general-purpose structure, JSONL for large-scale record processing, TOON for token-efficient LLM input. No single format is likely to replace all the rest. The better move is to choose the representation that fits the bottleneck you actually have.