JTON: A Token-Efficient JSON Superset with Zen Grid Tabular Encoding for Large Language Models

Gowthamkumar Nandakishore

cs.AIApr 7, 2026

JTON: A Token-Efficient JSON Superset with Zen Grid Tabular Encoding for Large Language Models

Authors: Gowthamkumar Nandakishore

Abstract

When LLMs process structured data, the serialization format directly affects cost and context utilization. Standard JSON wastes tokens repeating key names in every row of a tabular array--overhead that scales linearly with row count. This paper presents JTON (JSON Tabular Object Notation), a strict JSON superset whose main idea, Zen Grid, factors column headers into a single row and encodes values with semicolons, preserving JSON's type system while cutting redundancy. Across seven real-world domains, Zen Grid reduces token counts by 15-60% versus JSON compact (28.5% average; 32% with bare_strings). Comprehension tests on 10 LLMs show a net +0.3 pp accuracy gain over JSON: four models improve, three hold steady, and three dip slightly. Generation tests on 12 LLMs yield 100% syntactic validity in both few-shot and zero-shot settings. A Rust/PyO3 reference implementation adds SIMD-accelerated parsing at 1.4x the speed of Python's json module. Code, a 683-vector test suite, and all experimental data are publicly available.

Figures & tables

Rows	JSON Pretty	JSON Compact	Zen Grid	Zen Bare	$\Delta$ vs Compact
5	168	88	75	64	$-$ 14.8%
10	335	175	142	119	$-$ 18.9%
25	836	436	343	284	$-$ 21.3%
50	1,671	871	678	559	$-$ 22.2%
100	3,342	1,742	1,349	1,109	$-$ 22.6%
250	8,351	4,351	3,358	2,759	$-$ 22.8%

Table 1: Token counts by format and dataset size (employee records, 4 columns).

Figure 1: Token count scaling for employee records (4 columns, o200k_base tokenizer). Zen Grid savings increase with row count, converging to

\sim

23% at scale.

Dataset	Rows	Cols	JSON Tokens	Zen Tokens	Savings
Employees	100	4	1,742	1,349	$-$ 22.6%
Employees	500	4	8,702	6,709	$-$ 22.9%
Products	100	5	2,764	2,273	$-$ 17.8%
Products	500	5	13,838	11,347	$-$ 18.0%
Metrics	100	4	2,694	2,301	$-$ 14.6%
Metrics	500	4	13,472	11,479	$-$ 14.8%

Table 2: Token savings across different data shapes (100 and 500 rows).

Figure 2: Token savings (%) versus JSON formats converge rapidly with row count, reaching 23% versus compact and 59% versus pretty-printed by 1,000 rows.

Figure 3: Zen Grid token savings across different data shapes. Savings range from 15% (number-heavy metrics) to 23% (string-heavy employees).

Dataset	Rows	JSON Compact	Zen Bare	$\Delta$ Compact	$\Delta$ Pretty
Twitter (API)	20	3,673	1,422	$-$ 61.3%	$-$ 65.9%
GitHub (Events)	20	968	780	$-$ 19.4%	$-$ 43.8%
CITM (Ticketing)	20	871	612	$-$ 29.7%	$-$ 52.6%
Financial (Trades)	20	1,358	1,041	$-$ 23.3%	$-$ 48.5%
Weather (Stations)	25	1,911	1,316	$-$ 31.1%	$-$ 52.3%
Healthcare (Lab)	20	1,349	936	$-$ 30.6%	$-$ 53.3%

Table 3: Token counts and savings across seven real-world datasets (20–25 rows each, o200k_base tokenizer, Zen Grid with bare_strings=True ).

Figure 4: Token counts across seven real-world datasets. Zen Grid (green) consistently uses fewer tokens than both JSON compact and JSON pretty-printed. Savings range from 15% (GitHub) to 60% (Twitter) versus compact, and up to 61% with bare_strings .

Figure 5: Zen Grid token savings by dataset domain. Savings correlate with key name length and column count–datasets with longer, more descriptive keys achieve higher savings.

Dataset	JSON (ms)	JTON (ms)	Speedup
Twitter	0.090	0.058	1.55 $\times$
GitHub	0.043	0.036	1.20 $\times$
CITM	0.055	0.037	1.50 $\times$
Financial	0.083	0.059	1.40 $\times$
Weather	0.106	0.070	1.53 $\times$
Healthcare	0.088	0.056	1.58 $\times$

Table 4: Parse speed: jton.loads() vs json.loads() on real-world datasets (5,000 iterations, averaged).

Figure 6: Left: parse speedup per dataset. Right: absolute parse latency comparison. JTON achieves 1.2–1.6

\times

speedup across all real-world datasets.

Model	Family	JSON	Zen Grid	$\Delta$	$n$
GPT-5.1-codex	OpenAI	74.3%	71.4%	$-$ 2.9 pp	35
GPT-5.1	OpenAI	71.4%	62.9%	$-$ 8.6 pp	35
GPT-5-mini	OpenAI	71.4%	71.4%	0.0 pp	35
Gemini 3 Pro	Google	68.6%	68.6%	0.0 pp	35
Kimi K2	Moonshot	62.9%	68.6%	+5.7 pp	35
Qwen3 32B	Alibaba	60.0%	57.1%	$-$ 2.9 pp	35

Table 5: LLM accuracy (%) on real-world data across 10 models (7 datasets

\times

5 questions per format,

n

=35 each unless noted). Models sorted by JSON accuracy.

Question Type	JSON	Zen Grid	$\Delta$
Lookup	95.7%	95.7%	0.0 pp
Filtering	52.9%	51.4%	$-$ 1.4 pp
Count	51.4%	48.6%	$-$ 2.9 pp
Comparison	48.6%	50.0%	+1.4 pp
Aggregation	47.1%	51.4%	+4.3 pp
Overall	59.1%	59.4%	+0.3 pp

Table 6: Accuracy (%) by question type on real-world data (all 10 models combined).

Family	Models	JSON	Zen Grid	$\Delta$
OpenAI (GPT-5.x)	3	72.4%	68.6%	$-$ 3.8 pp
Google (Gemini)	1	68.6%	68.6%	0.0 pp
Moonshot (Kimi K2)	1	62.9%	68.6%	+5.7 pp
Alibaba (Qwen3)	1	60.0%	57.1%	$-$ 2.9 pp
Meta (Llama)	3	46.7%	49.5%	+2.9 pp
Open-source (GPT-OSS)	1	42.9%	45.7%	+2.9 pp

Table 7: Accuracy (%) by model family.

Figure 7: LLM accuracy on real-world datasets: JSON vs Zen Grid across 10 models. Four models improve with Zen Grid (green annotations), three are neutral, and three regress slightly. Overall: +0.3 pp.

Figure 8: Accuracy by question type on real-world data (10 models combined). Lookup remains perfectly robust (95.7%/95.7%); aggregation shows the largest improvement (+4.3 pp).

Figure 9: Accuracy by dataset domain. Performance varies by domain complexity–Twitter and GitHub (shorter values) show higher accuracy than financial and healthcare (complex numeric data).

Figure 10: Token savings: synthetic scaling trend (green line) versus real-world datasets (red diamonds). Real-world data achieves higher savings due to longer, more descriptive key names in production schemas.

Dataset	JSON Pretty	JSON Compact	CSV	Markdown	YAML	Zen Grid
Twitter	4,166	3,673	1,303	1,430	1,916	1,653
GitHub	1,388	968	688	792	1,185	968
Financial	1,023	643	408	505	840	516

Table 8: Token counts across six serialization formats on real-world data. Zen Grid achieves competitive token efficiency while preserving JSON’s type system.

Figure 11: Token counts (left) and savings vs JSON compact (right) across six serialization formats. CSV achieves the fewest tokens but loses type information. Zen Grid preserves JSON’s full type system while achieving substantial savings.

Rank	Format	Total Tokens	vs JSON Compact	JSON-compat.
1	JTON	144,159	$-$ 20.2%	Yes
2	TOON	146,113	$-$ 19.2%	No
3	JSON compact	180,725	–	Yes
4	YAML	220,129	+21.8%	No
5	JSON pretty	282,332	+56.2%	Yes
6	XML	332,171	+83.8%	No

Table 9: Overall token efficiency ranking across 6 datasets and 7 formats (total tokens, o200k_base ).

Model	Family	Few-shot	Zero-shot
GPT-5-mini	OpenAI	100%	100%
GPT-5.1	OpenAI	100%	100%
GPT-4o	OpenAI	100%	100%
Claude Sonnet 4	Anthropic	100%	100%
Claude 3.5 Haiku	Anthropic	100%	100%
Claude 3 Haiku	Anthropic	100%	100%

Table 10: Zen Grid generation validity (%) by model and prompting strategy. All 12 models achieve 100% validity in both modes.

Figure 12: Cost–accuracy tradeoff across 10 LLMs. Each model appears twice: as a red point (JSON) and green point (Zen Grid), connected by an arrow. Models that move left without moving down achieve a Pareto improvement (lower cost, same or better accuracy).

Rows	Size	Parse (MB/s)		Speedup	Serialize (MB/s)
	(KB)	stdlib	JTON		stdlib	JTON
100	5.5	34.5	49.9	1.44 $\times$	51.8	98.4
500	27.8	27.7	13.4	0.48 $\times$ $\dagger$	29.5	32.1
1,000	55.6	18.4	21.4	1.16 $\times$	18.1	25.5
5,000	282.6	35.0	45.4	1.30 $\times$	41.0	83.6

Table 11: Parsing and serialization throughput on synthetic employee records.

File	Size (KB)	stdlib (MB/s)	JTON (MB/s)	Speedup
canada.json	2,198	16.0	29.7	1.85 $\times$
citm_catalog.json	1,687	41.9	66.1	1.58 $\times$
twitter.json	617	48.5	50.4	1.04 $\times$
github.json	55	128.9	98.7	0.77 $\times$

Table 12: Parsing speed on standard JSON benchmark files.

Figure 13: Parsing and serialization throughput. JTON achieves 1.2–1.9

\times

parse speedup on large files and up to 3.7

\times

serialization speedup with Zen Grid output.

Rows	stdlib JSON (MB/s)	JTON JSON (MB/s)	JTON Zen Grid (MB/s)
100	51.8	98.4	88.3
500	29.5	32.1	75.4
1,000	18.1	25.5	30.3
5,000	41.0	83.6	149.9

Table 13: Serialization throughput: JSON vs Zen Grid output.

Format	Tokens/call	Monthly tokens	Monthly cost
JSON Compact	8,702	8.70B	$21,755
Zen Grid	6,709	6.71B	$16,773
Zen Grid + Bare	5,509	5.51B	$13,773
Savings (Zen Grid vs JSON)			$4,982/mo
Savings (Zen Bare vs JSON)			$7,982/mo

Table 14: Estimated monthly API cost savings (GPT-4o pricing: $2.50/1M input tokens).

Token Efficiency

Token efficiency studies how to reduce language-model token use, cost, and latency while preserving task quality and equitable access.

See all 30 papers

ONTO: A Token-Efficient Columnar Notation for LLM Input Optimization
Apr 19, 2026Harshavardhanan DeekeswarLLM Inference Efficiency LLM Input Optimization
Independent Researcher · Chennai, India
Notation Matters: A Benchmark Study of Token-Optimized Formats in Agentic AI Systems
May 28, 2026Lorenz Kutschka, Bernhard GeigerTool-Augmented Language Model Agents AI Agent Evaluation
Know Center Research GmbH / Sandgasse 34, A-8010 Graz · Signal Processing and Speech Communication, Graz University of Technology / Inffeldgasse 16c, A-8010 Graz · Graz Center for Machine Learning // A-8010 Graz
TruncProof: A Guardrail for LLM-based JSON Generation under Token-Length Constraints
May 13, 2026Yoshio Kato, Shuhei TarashimaConstrained Decoding Structured Output Generation
NTT DOCOMO BUSINESS, Inc., Japan

Apr 19, 2026J/K move · Enter open · S save

ONTO: A Token-Efficient Columnar Notation for LLM Input Optimization

Harshavardhanan Deekeswar

Independent Researcher · Chennai, India

LLM Inference Efficiency LLM Input Optimization Token Efficiency

Open paper AskPDF arXiv

Serialization formats designed for document interchange impose structural overhead that becomes prohibitive when large language models consume operational data at scale. A modest dataset of 1,000 IoT sensor readings serialized as JSON requires approximately 80,000 tokens - the majority spent on repeated field names, nested braces, and structural punctuation rather than semantic content. We present ONTO (Object Notation for Token Optimization), a columnar notation that declares field names once per entity and arranges values in pipe-delimited rows with indentation-based hierarchy. This schema-once, data-many design eliminates per-record key repetition while preserving human readability and nested structure support. Evaluation across three synthetic operational datasets demonstrates 46-51% token reduction versus JSON, with stable scaling from 100 to 1,000 records. Controlled inference benchmarks on Qwen2.5-7B show corresponding 5-10% latency improvement. Comprehension validation confirms no material degradation in LLM task accuracy across lookup, counting, extraction, and aggregation operations when format context is provided. Ablation analysis reveals that key repetition accounts for the majority of JSON overhead, with indentation costs in nested structures explaining the 4-percentage-point gap between flat and hierarchical data. ONTO occupies a previously unfilled position in the serialization landscape: columnar efficiency with hierarchical structure, optimized for LLM context windows rather than document interchange. Code and specification are available at https://github.com/harsh-aranga/onto.

Abstract

Token Efficiency

Explore similar work

ONTO: A Token-Efficient Columnar Notation for LLM Input Optimization

Notation Matters: A Benchmark Study of Token-Optimized Formats in Agentic AI Systems

TruncProof: A Guardrail for LLM-based JSON Generation under Token-Length Constraints