Format documentation loves toy examples — three rows, fake names, five columns. That's fine for learning the syntax, but it doesn't tell you whether a format handles the shapes you actually deal with at work. This article skips the toys. Below are the data patterns that come up constantly in real backend development — product catalogs, audit logs, metrics tables, config objects, financial transactions — shown in both JSON and TOON side-by-side, so you can see exactly what you're saving and where TOON earns its keep. All data is realistic; no foo, bar, or placeholder names in sight. For background on the format itself, see the TOON syntax guide.

E-Commerce Product Catalog

A products array is probably the single most common thing developers send to an LLM — "classify these items", "find the cheapest in each category", "flag anything out of stock with a price above $50". Here's a realistic catalog slice in JSON first:

json
[
  {"id":"PRD-1041","name":"Logitech MX Master 3S","sku":"LOG-MX3S-GRY","price":99.99,"inStock":true,"category":"Peripherals"},
  {"id":"PRD-1042","name":"Samsung 970 EVO Plus 1TB","sku":"SAM-970P-1TB","price":89.99,"inStock":true,"category":"Storage"},
  {"id":"PRD-1043","name":"Keychron K2 Pro","sku":"KEY-K2P-BLK","price":119.99,"inStock":false,"category":"Peripherals"},
  {"id":"PRD-1044","name":"Elgato Stream Deck MK.2","sku":"ELG-SD-MK2","price":149.99,"inStock":true,"category":"Streaming"},
  {"id":"PRD-1045","name":"WD Blue 2TB HDD","sku":"WD-BLU-2TB","price":54.99,"inStock":true,"category":"Storage"},
  {"id":"PRD-1046","name":"Razer DeathAdder V3","sku":"RZR-DAV3-BLK","price":69.99,"inStock":true,"category":"Peripherals"},
  {"id":"PRD-1047","name":"Focusrite Scarlett Solo","sku":"FOC-SC-SOLO","price":119.99,"inStock":false,"category":"Audio"}
]

Now the same catalog in TOON. Column headers are declared once; each row is just values:

text
products[7]{id,name,sku,price,inStock,category}:
  PRD-1041,Logitech MX Master 3S,LOG-MX3S-GRY,99.99,true,Peripherals
  PRD-1042,Samsung 970 EVO Plus 1TB,SAM-970P-1TB,89.99,true,Storage
  PRD-1043,Keychron K2 Pro,KEY-K2P-BLK,119.99,false,Peripherals
  PRD-1044,Elgato Stream Deck MK.2,ELG-SD-MK2,149.99,true,Streaming
  PRD-1045,WD Blue 2TB HDD,WD-BLU-2TB,54.99,true,Storage
  PRD-1046,Razer DeathAdder V3,RZR-DAV3-BLK,69.99,true,Peripherals
  PRD-1047,Focusrite Scarlett Solo,FOC-SC-SOLO,119.99,false,Audio
The six column headers in TOON are written exactly once. In JSON they repeat on every row. By row 3 the header has already paid for itself in token savings — and on a 200-row catalog the difference is dramatic. Use the OpenAI tokenizer to verify the savings for your own data.

User Activity / Audit Log

Audit logs are exactly the kind of data you'd feed to an LLM with a prompt like "summarise what this user did in the last hour" or "flag any suspicious access patterns". They're high-volume, repetitive, and the column names are identical on every row. Audit trails also tend to be the first thing that blows your context window when you paste them as JSON. Here's a realistic 9-row log in TOON:

text
auditLog[9]{userId,action,resourceId,resourceType,timestamp,ip}:
  U-8821,LOGIN,,session,2024-11-14T08:02:11Z,203.0.113.47
  U-8821,VIEW,DOC-4490,document,2024-11-14T08:03:44Z,203.0.113.47
  U-8821,DOWNLOAD,DOC-4490,document,2024-11-14T08:03:51Z,203.0.113.47
  U-8821,VIEW,DOC-4491,document,2024-11-14T08:05:02Z,203.0.113.47
  U-8821,EDIT,DOC-4491,document,2024-11-14T08:07:39Z,203.0.113.47
  U-8821,SHARE,DOC-4491,document,2024-11-14T08:08:12Z,203.0.113.47
  U-8821,VIEW,USR-0055,user_profile,2024-11-14T08:09:58Z,203.0.113.47
  U-8821,VIEW,USR-0056,user_profile,2024-11-14T08:10:03Z,203.0.113.47
  U-8821,LOGOUT,,session,2024-11-14T08:11:22Z,203.0.113.47

The equivalent JSON would repeat "userId", "action", "resourceId", "resourceType", "timestamp", and "ip" on all nine rows — 54 key repetitions for six field names. In TOON they appear exactly once. For audit logs with hundreds of entries, that's the difference between fitting the data in your prompt and not.

API Rate Limit / Metrics Data

Operational metrics — latency percentiles, error rates, throughput — are another natural fit for TOON. The data is numeric-heavy and perfectly tabular. You might send this to an LLM to ask "which endpoints have p99 latency above 500ms?" or "where is error rate trending upward?" This is the shape of data you'd typically see coming out of a Node.js metrics pipeline or a Prometheus scrape:

text
apiMetrics[8]{endpoint,method,p50ms,p99ms,errorRate,callsPerDay}:
  /api/v2/products,GET,42,118,0.002,84200
  /api/v2/products/:id,GET,38,95,0.001,31500
  /api/v2/orders,POST,210,880,0.015,4800
  /api/v2/orders/:id,GET,55,201,0.003,19200
  /api/v2/cart,PUT,95,430,0.008,22100
  /api/v2/search,GET,310,1240,0.021,61000
  /api/v2/users/:id,GET,29,88,0.001,9700
  /api/v2/checkout,POST,540,2100,0.034,3200

The LLM can immediately answer questions about this table without any context overhead. Note that /api/v2/search and /api/v2/checkout both stand out with high p99 and elevated error rates — exactly the kind of pattern an LLM can surface instantly when you present the data cleanly.

Nested Configuration Object

TOON handles more than tabular data. For structured objects — the kind of thing you'd find in an app's runtime config — TOON uses an inline object notation with nested structure. Think of this as a counterpart to serialization formats like TOML or YAML, but leaner. Here's a realistic app config showing server settings, database settings, and feature flags:

json
{
  "server": {
    "host": "0.0.0.0",
    "port": 8080,
    "tlsEnabled": true,
    "requestTimeoutMs": 30000
  },
  "database": {
    "host": "db.internal.example.com",
    "port": 5432,
    "name": "commerce_prod",
    "poolSize": 20,
    "sslRequired": true
  },
  "features": {
    "newCheckoutFlow": true,
    "recommendationEngine": false,
    "darkMode": true,
    "betaDashboard": false
  }
}

The same config in TOON object notation — keys are unquoted, nesting uses inline braces:

text
{
  server:{host:0.0.0.0,port:8080,tlsEnabled:true,requestTimeoutMs:30000},
  database:{host:db.internal.example.com,port:5432,name:commerce_prod,poolSize:20,sslRequired:true},
  features:{newCheckoutFlow:true,recommendationEngine:false,darkMode:true,betaDashboard:false}
}
TOON's object syntax doesn't quote keys unless a value contains a comma or colon. In the database block above, host:db.internal.example.com is fine as-is — no quotes needed because the value contains neither. If a value does contain a comma or colon, wrap it in double quotes: dsn:"host:5432,sslmode=require".

Financial Transactions

Financial data is another high-value LLM use case: fraud detection hints, reconciliation checks, categorisation. The mix of string IDs, numeric amounts, currency codes, status enums, and timestamps maps cleanly to TOON's tabular format. Here's a realistic transaction slice:

text
transactions[9]{txId,amount,currency,from,to,status,timestamp}:
  TXN-88201,1250.00,GBP,ACC-1041,ACC-2209,settled,2024-11-14T09:15:00Z
  TXN-88202,89.99,USD,ACC-3301,ACC-0047,settled,2024-11-14T09:16:34Z
  TXN-88203,4500.00,EUR,ACC-2001,ACC-5512,pending,2024-11-14T09:18:02Z
  TXN-88204,22.50,USD,ACC-0099,ACC-3301,settled,2024-11-14T09:21:47Z
  TXN-88205,750.00,GBP,ACC-5512,ACC-1041,failed,2024-11-14T09:25:10Z
  TXN-88206,12000.00,USD,ACC-7700,ACC-2001,pending,2024-11-14T09:28:55Z
  TXN-88207,310.00,EUR,ACC-1041,ACC-0099,settled,2024-11-14T09:31:22Z
  TXN-88208,55.00,USD,ACC-3301,ACC-7700,settled,2024-11-14T09:33:40Z
  TXN-88209,8900.00,GBP,ACC-2209,ACC-5512,flagged,2024-11-14T09:37:15Z

Paste this into a prompt alongside "flag any transactions over £5,000 or with status flagged or failed" and the model will answer in seconds. The TOON representation is compact enough that you'd comfortably fit several hundred rows in a single prompt without hitting context limits on most models.

Combining Tabular and Object Data in One Document

Here's something neither JSON nor CSV handles cleanly: a document that has both a metadata header (a single config object) and a data table in the same payload. Think of a report with a context block at the top — who generated it, what time period it covers, what filters were applied — followed by the actual data rows. In JSON you'd need to wrap everything in an envelope object with a "meta" key and a "rows" key, which adds another layer of nesting. CSV can't do it at all. TOON handles it natively:

text
{report:weekly_sales,generatedAt:2024-11-14T10:00:00Z,region:EMEA,currency:EUR,generatedBy:analytics-service}

salesByRep[6]{repId,repName,deals,revenue,avgDealSize,quota}:
  REP-101,Marta Kowalski,14,84200.00,6014.28,75000
  REP-102,James Okafor,11,61500.00,5590.90,75000
  REP-103,Yuki Tanaka,18,102400.00,5688.88,90000
  REP-104,Sofia Andersen,9,47800.00,5311.11,75000
  REP-105,Liam Byrne,16,93100.00,5818.75,90000
  REP-106,Priya Nair,21,118600.00,5647.61,100000

The first line is a TOON object — the report metadata. The blank line separates it from the tabular section that follows. A single decode() call from @toon-format/toon returns both. You can send this entire document to an LLM with a question like "which reps are on track to hit quota?" and it has everything it needs: the report context and the data, in one compact payload.

This mixed format is particularly powerful for LLM pipelines. Rather than building a JSON envelope with nested keys, you write a flat header object + a named table. The model reads it naturally, and your code to generate it is trivial. Use the JSON to TOON converter to transform existing JSON payloads, or the TOON Formatter to clean up and validate hand-written TOON.

Using the npm Package

All of these examples can be encoded and decoded programmatically. The @toon-format/toon package is the reference implementation. Install it into any Node.js or browser project:

bash
npm install @toon-format/toon

Then encode your data before sending it to any LLM API, and decode the response on the way back:

ts
import { encode, decode } from '@toon-format/toon';

const transactions = [
  { txId: 'TXN-88201', amount: 1250.00, currency: 'GBP', from: 'ACC-1041', to: 'ACC-2209', status: 'settled', timestamp: '2024-11-14T09:15:00Z' },
  { txId: 'TXN-88202', amount: 89.99,   currency: 'USD', from: 'ACC-3301', to: 'ACC-0047', status: 'settled', timestamp: '2024-11-14T09:16:34Z' },
  // ...more rows
];

// Compact TOON string — send this to your LLM prompt
const toonPayload = encode(transactions);

// When the LLM returns TOON, decode back to a JS array
const decoded = decode(toonPayload);
console.log(decoded[0].status); // "settled"

Wrapping Up

The patterns above — product catalogs, audit logs, metrics tables, config objects, financial data, mixed header+table documents — cover the vast majority of structured data that developers actually send to LLMs. TOON handles all of them well, and the token savings are significant in every case. The core rule is simple: JSON repeats key names on every row; TOON doesn't. For tabular data serialization that's going into an LLM context window, that repetition is pure waste.

To convert existing JSON into TOON, use the JSON to TOON converter. To go the other direction after an LLM returns TOON, use the TOON to JSON converter. The TOON Formatter cleans and validates TOON strings, and the TOON Validator will catch syntax errors before they reach your pipeline. The npm package @toon-format/toon handles encoding and decoding in two lines of code — all the examples above work out of the box.

← All TOON articles Browse all categories →