TOON (Token-Oriented Object Notation) is a data serialization format designed specifically for LLM prompts to be highly efficient. It dramatically reduces token usage by 30-60% compared to JSON while remaining structured and human-readable. By using a tabular format for arrays and minimal syntax for objects, TOON makes your data cheaper and faster to process with AI models.

What's the difference between TOON and JSON?

The key difference is token efficiency. JSON is verbose, with brackets, quotes, and commas that consume tokens. TOON is a more compact syntax designed for LLMs, representing arrays as tables with headers and using minimal punctuation. This efficiency directly translates to significant cost savings on your LLM API bills, especially for large or repeated datasets.

How much can I save with TOON?

You can typically expect to save 30-60% on LLM tokens compared to using JSON. For large datasets or frequent API calls, this translates directly into significant cost savings. Data with repeated structures, like API responses or database results, often sees savings at the higher end of this range (40-60%).

Is TOON compatible with all LLMs?

Yes. TOON is a simple text format that works flawlessly with all major large language models, including those from OpenAI (GPT-4), Anthropic (Claude), Google (Gemini), and Meta (LLaMA). Since any LLM can process plain text, they can all be instructed to understand and parse the TOON format with a simple instruction in your prompt.

Can I convert TOON back to JSON?

Absolutely. TOON is fully and losslessly reversible. Our converter tool supports bidirectional conversion, meaning you can convert TOON back to the exact original JSON structure without any data loss. This allows you to use TOON for efficiency and then convert back to JSON for compatibility with other tools.

What types of data work best with TOON?

TOON can represent any valid JSON data, but it delivers the highest token savings (40-60%) on uniform tabular data. This includes database query results, API responses with lists of objects, analytics data, or product catalogs. While TOON fully supports nested objects and arrays, the token reduction is most dramatic with flatter, more repetitive data structures.

Is my data safe when using this converter?

100% safe. All conversion from JSON to TOON (and back) happens locally in your browser. Your data is never sent to any server, never stored, and never seen by us. The converter even works offline once the page has loaded, guaranteeing your information remains private.

Yes, completely free. Both this TOON converter and the underlying TOON format specification are open and free to use without any limits, file size restrictions, or premium features. It's an open-source effort to make working with LLMs more efficient for everyone.

لماذا يتفوق TOON على التنسيقات الأخرى

ماجستير

المعايير

خرقة

إذا كنت تقوم بإنشاء تطبيقات LLM، وتحديدًا أنظمة أو وكلاء الاسترجاع المعزز (RAG) الذين يستهلكون مجموعات كبيرة من البيانات، فمن المحتمل أنك تخوض حربًا مستمرة على جبهتين: تكلفة الرمز المميز و حدود نافذة السياق.

لسنوات عديدة، كانت لغة JSON هي اللغة المشتركة الافتراضية لتبادل البيانات. إنها قابلة للقراءة من قبل الإنسان (في الغالب) وفي كل مكان. ولكن عند لصق مصفوفة JSON مكونة من 500 صف في الموجه، فإنك تحرق آلاف الرموز المميزة على أسماء الحقول المتكررة ("id":، "name":، "email":) التي تحمل قيمة دلالية صفرية للصف المحدد.

أدخل تون. إنه تنسيق مصمم خصيصًا لحل مشكلة نسبة الإشارة إلى الضوضاء في مدخلات LLM. لقد قمت بالتعمق في أحدث المعايير، وكانت النتائج مذهلة: TOON لا يوفر المساحة فحسب؛ إنها في الواقع تساعد نماذج مثل GPT-5-nano وGemini-2.5-flash على فهم البيانات بشكل أفضل.

دعونا نحلل سبب تفوق TOON على البرامج ذات الوزن الثقيل (JSON وCSV وYAML وXML) وننظر إلى الأرقام الأولية.

فخ الإسهاب: JSON vs.TOON

أكبر عدو لكفاءة الرمز المميز هو تكرار البنية. دعونا نلقي نظرة على مجموعة بيانات تحليلات السلاسل الزمنية القياسية. في JSON، تحمل كل نقطة بيانات حمولة مخططها.

JSON (قياسي) الرموز المستخدمة في المعيار: 22,250

هذا كثير من المساحة الضائعة. الآن، انظر إلى ما يعادل TOON. يقوم TOON بتعريف المخطط مرة واحدة في الرأس ثم يتحول إلى تخطيط كثيف بنمط CSV للقيم.

تون الرموز المستخدمة في المعيار: 9,120

النتيجة: انخفاض هائل 59.0% في استخدام الرمز المميز.

من خلال إزالة المفاتيح المتكررة، يتيح لك TOON إمكانية ملاءمة المزيد من السجل في نافذة سياق النموذج. ولكن الأهم من ذلك، على عكس ملف CSV، أنه يحافظ على الوعي بالنوع والبنية الواضحة من خلال تعريف الرأس المقاييس[5]{...}.

لماذا لا نستخدم ملف CSV فقط؟

هذه هي الحجة المضادة الأكثر شيوعا. "إذا كنت تريد بيانات ثابتة، فما عليك سوى استخدام ملف CSV."

المشكلة هي أن بيانات العالم الحقيقي نادرًا ما تكون مسطحة تمامًا. ينهار ملف CSV تمامًا في اللحظة التي تتداخل فيها الهياكل، أو القوائم داخل الكائنات، أو الأوصاف المعقدة التي تحتوي على فواصل وعلامات اقتباس.

في المعايير، وتحديدًا مسار الهيكل المختلط (الذي يتضمن طلبات التجارة الإلكترونية وسجلات الأحداث)، تم استبعاد ملف CSV بالكامل لأنه لا يمكنه تمثيل البيانات دون تسوية البيانات مع فقدان البيانات.

يتعامل TOON مع هذا بأمان. يسمح بالكائنات المتداخلة أثناء تحسين المصفوفات. في اختبار 100 مستودع GitHub (التي تحتوي على أوصاف نصية مختلطة وبيانات تعريفية)، كانت فجوة الكفاءة واضحة:

JSON: 15,145 رمزًا

TOON: 8,745 رمزًا (توفير 42.3%)

حتى مقابل JSON Compact (المُصغَّر)، ما زال TOON يحقق توفيرًا أكبر بنسبة 24% تقريبًا. عندما تدفع مقابل كل مليون رمز، فهذا يمثل عائدًا فوريًا على الاستثمار.

الدقة: الفائز المفاجئ

هنا هو الجزء الذي فاجأني. عادة، عند ضغط البيانات، تفقد الوضوح. تتوقع أن يواجه LLM صعوبة في تحليل تنسيق أكثر كثافة. وتظهر المعايير عكس ذلك.

من خلال 209 أسئلة لاسترجاع البيانات تم اختبارها على نماذج مثل Claude Haiku وGemini Flash وGPT-5-nano، حققت TOON دقة استرجاع بنسبة 73.9%، مقارنة بـ JSON القياسي 69.7%.

لماذا؟ من المحتمل أن يعود الأمر إلى الحمل المعرفي (أو ما يعادله من LLM).

ضوضاء أقل: ليس من الضروري أن يستقبل النموذج آلاف الرموز المميزة "المفتاحية" المتكررة. القيم ذات الصلة أقرب إلى بعضها البعض في آلية الانتباه.

بيانات التعريف الصريحة: تتضمن رؤوس TOON العدد ([N]) وأسماء الحقول بشكل صريح.

الوعي بالبنية: في الاختبارات التي تسأل عن بنية مجموعة البيانات (على سبيل المثال، "كم عدد الصفوف الموجودة؟")، حققت TOON دقة بنسبة 88%، بينما تأخرت JSON وXML. يعمل العدد الصريح في رأس TOON (repositories[100]) بمثابة تلميح يمنع النموذج من الاضطرار إلى "عد" الرموز المميزة يدويًا، وهو ما يشتهر به طلاب LLM.

إرهاق XML وYAML

يجب أن نذكر بإيجاز المتنافسين الآخرين.

XML هو الخاسر الأكبر هنا. فهو مطول، وصعب القراءة، ومكلف في المعالجة. في المعايير، استخدم XML باستمرار معظم الرموز المميزة (أكثر من 5000 لمجموعة سجلات موحدة للموظفين والتي يمثلها TOON بحوالي 2700) وكان لديه أقل دقة (67.1٪).

أداء YAML أفضل من XML ولكنه لا يزال يعاني من تضخم الرمز المميز مقارنةً بـ TOON. في حين أن YAML يعد أمرًا رائعًا لملفات التكوين البشرية، إلا أن طبيعته الحساسة للمسافات البيضاء وتكرار المفاتيح يجعله دون المستوى الأمثل لسياق البيانات كبيرة الحجم. في اختبار "طلبات التجارة الإلكترونية"، استخدمت YAML رموزًا أكثر بنسبة 14% تقريبًا من TOON.

متى يتم التبديل؟

البيانات قاطعة إلى حد ما. إذا كنت تتعامل مع:

قوائم العناصر: السجلات أو سجلات المعاملات أو نتائج البحث أو كتالوجات المنتجات.

خطوط أنابيب RAG: حيث يمكنك استرداد أجزاء من البيانات من قاعدة البيانات لتغذيتها في الموجه.

واجهات برمجة التطبيقات ذات الحجم الكبير: حيث يكون النطاق الترددي وزمن الوصول مهمًا.

يقدم TOON سيناريو "أفضل ما في العالمين". يمكنك الحصول على كثافة CSV مع السلامة الهيكلية لـ JSON.

في الاختبارات المعيارية، حقق GPT-5-nano دقة مذهلة 90.9% في البيانات بتنسيق TOON. يشير هذا إلى أن النماذج الأحدث والأكثر ذكاءً أصبحت ماهرة بشكل متزايد في تحليل هذه التنسيقات المحسنة، مما يعني أن "عقوبة سهولة القراءة" للابتعاد عن JSON هي صفر فعليًا بالنسبة للجهاز.

إذا كنت لا تزال تقوم بتنسيق سياق RAG الخاص بك كـ JSON.stringify(data, null, 2)، فأنت تدفع فعليًا "ضريبة قابلية القراءة" على كل استدعاء لواجهة برمجة التطبيقات (API). ربما حان الوقت لتبديل التنسيقات.