Durante años, JSON ha sido una de esas piezas invisibles que sostienen internet sin hacer demasiado ruido. Está en APIs, microservicios, configuraciones, integraciones, paneles internos y prácticamente cualquier sistema moderno que necesite intercambiar datos estructurados. Por eso resulta tentador exagerar cuando aparece un formato nuevo y proclamar que JSON ha muerto. La realidad, al menos de momento, es bastante menos dramática: JSON no está muriendo, pero sí empieza a mostrar sus límites cuando se usa como lenguaje de intercambio con modelos de lenguaje que cobran y razonan por tokens.
Ese es el contexto en el que ha empezado a ganar atención TOON, siglas de Token-Oriented Object Notation. El proyecto se presenta como una codificación compacta y legible del modelo de datos de JSON, pensada específicamente para prompts de LLM. La promesa es sencilla de entender: conservar los mismos objetos, arrays y primitivas que JSON, pero con una sintaxis que elimine buena parte del ruido visual que ayuda a los humanos, aunque no siempre a los modelos.
En otras palabras, TOON no intenta sustituir JSON en toda la informática. No quiere ser el nuevo formato universal para APIs, almacenamiento, frontends o contratos entre servicios. Su ambición es más concreta: convertirse en una capa de traducción eficiente cuando una aplicación necesita enviar datos estructurados a un modelo de lenguaje. De hecho, el propio repositorio oficial lo explica así: usar JSON de forma programática y codificarlo como TOON para la entrada del LLM.
La lógica detrás de esta propuesta encaja bien con cómo funciona hoy la economía de la IA generativa. Cuando una aplicación llama a un modelo, no le envía “objetos” en sentido informático, sino secuencias tokenizadas. En ese proceso, las llaves, las comillas, las comas, las repeticiones de claves y otros elementos sintácticos que hacen cómodo JSON para los programadores acaban convirtiéndose en coste, contexto ocupado y más material que el modelo debe procesar. Esa diferencia parece menor en mensajes pequeños, pero empieza a pesar más cuando se envían listas largas, registros repetitivos o estructuras de datos amplias.
TOON quiere quitar ruido sin perder estructura
La propuesta técnica de TOON mezcla dos ideas que ya resultan familiares. Para objetos anidados usa una estructura por indentación, cercana a YAML. Para arrays uniformes de objetos utiliza una disposición tabular que recuerda a CSV, declarando los campos una sola vez y colocando después una fila por cada elemento. El resultado, según el proyecto, es una representación sin pérdida del mismo modelo de datos que JSON, pero más ligera en tokens y más fácil de seguir para un LLM.
Ahí está una de las claves de por qué este formato está llamando la atención. No se limita a quitar caracteres. También intenta exponer mejor la estructura. En la web oficial, TOON sostiene que alcanza un 74 % de precisión frente al 70 % de JSON en benchmarks de estructura mixta sobre cuatro modelos, al tiempo que reduce alrededor de un 40 % el número de tokens. Son cifras interesantes, aunque conviene leerlas con prudencia porque proceden del propio proyecto y porque el benchmark se centra en recuperación e interpretación de datos, no en todos los posibles usos de un LLM.
Ese matiz es importante. Un análisis crítico publicado meses después de los benchmarks oficiales recordaba precisamente que estas pruebas no miden si el modelo “programa mejor” o “responde mejor” en general, sino cómo entiende y extrae información cuando los datos se presentan en formatos distintos. Dicho de otro modo, TOON puede ser útil como formato de entrada estructurada, pero no hay evidencia suficiente para concluir que vaya a mejorar por sí solo cualquier sistema basado en LLM.
No es un sustituto universal de JSON
Otro punto que rebaja bastante el tono apocalíptico es que el propio proyecto reconoce límites claros. En su documentación, TOON afirma que su punto fuerte está en arrays uniformes de objetos y en datos donde la estructura repetitiva permite ahorrar muchas repeticiones. También admite que, para estructuras profundamente anidadas o datos no uniformes, JSON puede ser más eficiente. Es decir, ni siquiera sus autores sostienen que TOON gane siempre.
Además, sigue habiendo una barrera práctica importante: la herramienta y su ecosistema todavía están verdes frente a JSON. La especificación oficial aparece como Working Draft en su versión 3.0, publicada en noviembre de 2025. Hay implementaciones en TypeScript, Python, Go, Rust y .NET, pero el grado de adopción está a años luz del ecosistema que JSON ha construido durante décadas en lenguajes, frameworks, bases de datos, navegadores y sistemas operativos.
Eso obliga a poner el debate en su sitio. La pregunta correcta no es si JSON va a desaparecer, sino si, en determinados flujos de trabajo con modelos, tiene sentido introducir un paso previo de conversión para reducir tokens y estructurar mejor el input. Y ahí la respuesta empieza a ser bastante más razonable. En una arquitectura real, una aplicación podría seguir trabajando internamente con JSON, convertir a TOON justo antes de llamar al modelo y, si fuera necesario, volver a traducir la salida después. Ese enfoque no exige reescribir sistemas enteros, solo añadir una optimización en el borde donde vive el coste de inferencia.
Lo que realmente cambia en la era de los LLM
Más allá de si TOON acaba consolidándose o no, el debate apunta a una transformación más profunda. Durante mucho tiempo, los formatos de datos se diseñaban sobre todo pensando en legibilidad humana, interoperabilidad y facilidad de parseo por software tradicional. En la era de los LLM aparece una variable nueva: el coste tokenizado de la estructura. Y esa variable ya no es teórica. Influye en precio, latencia y ventana de contexto.
Por eso el verdadero titular quizá no sea que JSON esté muriendo, sino que deja de ser neutro cuando entra en un flujo de IA generativa. Lo que antes era un formato cómodo y suficientemente eficiente para casi todo, ahora puede resultar verboso y caro en ciertos usos. Eso no invalida JSON como estándar generalista. Pero sí abre espacio para formatos intermedios, más compactos y diseñados con modelos en mente.
Si TOON acabará siendo uno de esos formatos o si será solo un experimento influyente todavía está por ver. Hoy por hoy, parece más sensato tratarlo como una idea seria, útil en escenarios concretos y todavía en evolución, no como el heredero universal de JSON. La industria del software rara vez abandona de golpe una pieza tan central. Pero sí suele empezar a rodearla de capas nuevas cuando cambian las reglas del juego. Y la IA, claramente, está cambiando esas reglas.
Preguntas frecuentes
¿Qué es TOON y para qué sirve?
TOON, o Token-Oriented Object Notation, es un formato que codifica el mismo modelo de datos que JSON, pero con menos ruido sintáctico y con foco en reducir tokens en prompts para LLM.
¿TOON reemplaza a JSON en APIs y microservicios?
No. El propio proyecto lo plantea como una capa de traducción para entrada de modelos, no como sustituto universal de JSON en todo el software.
¿Cuánto ahorro de tokens promete TOON frente a JSON?
La web oficial habla de alrededor de un 40 % menos de tokens en benchmarks de estructura mixta, aunque esas cifras deben interpretarse con cautela porque proceden del propio proyecto.
¿Hay casos en los que JSON siga siendo mejor que TOON?
Sí. La documentación de TOON reconoce que en datos muy anidados o no uniformes JSON puede resultar más eficiente.
