TOON vs. JSON: o que muda na prática e quando vale usar

A discussão sobre TOON vs. JSON começou a ganhar força por um motivo bem específico: com LLMs, formato de dados não é apenas uma questão de legibilidade ou compatibilidade. Agora, também virou uma questão de custo por token.

É nesse contexto que o TOON aparece. A proposta do formato é representar os mesmos dados do JSON de forma mais compacta, reduzindo a quantidade de tokens enviados ao modelo. Na prática, ele tenta fazer com dados estruturados o que muita gente já faz manualmente com prompts: cortar tudo o que parece excesso e deixar apenas o que realmente importa.

A ideia parece boa. E, em alguns casos, realmente é.

O problema é que a comparação entre TOON vs. JSON costuma ser apresentada de um jeito que favorece demais o TOON. Quase sempre, ele é comparado com JSON formatado para leitura humana, cheio de espaços, quebras de linha e indentação. Isso aumenta artificialmente a vantagem. Quando a comparação é feita com JSON minificado, a diferença continua existindo em alguns cenários, mas fica bem menos impressionante.

O que é TOON

TOON significa Token-Oriented Object Notation. É um formato criado para serializar dados de forma mais compacta em prompts com LLMs, preservando o modelo conceitual do JSON, mas tentando gastar menos tokens.

Na prática, o TOON reduz repetições estruturais. Em vez de repetir o nome de cada chave em todos os objetos de uma lista, ele declara o esquema uma vez e depois organiza os valores em linhas compactas. A proposta é funcionar especialmente bem com dados tabulares ou com muitos registros parecidos.

Ele não tenta substituir o JSON em APIs, sistemas ou integrações tradicionais. O foco é outro: ser uma camada mais eficiente para enviar dados estruturados a modelos de linguagem.

O que é JSON e por que ele continua sendo o padrão

O JSON continua sendo o padrão porque resolve muito bem o problema da comunicação entre sistemas. Ele é simples, previsível, universal e tem um ecossistema maduro de ferramentas em qualquer linguagem ou framework moderno.

Por isso, quando alguém compara TOON vs. JSON, vale fazer uma distinção importante. Existe o JSON como formato de infraestrutura, usado em APIs, bancos de dados, sistemas e integrações. E existe o JSON como formato de prompt, usado para passar dados ao modelo.

No primeiro caso, o JSON continua difícil de bater. No segundo, a conversa fica mais aberta.

O ponto não é que o JSON tenha se tornado ruim. O ponto é que, para LLMs, especialmente em grandes volumes de dados, ele pode carregar repetições que aumentam o custo sem trazer ganho proporcional.

TOON vs. JSON: qual é a diferença na prática

A diferença prática entre TOON e JSON aparece mais em dados uniformes do que em estruturas arbitrárias.

Quando você tem uma lista grande de objetos com os mesmos campos, o JSON repete o nome de cada chave em todos os registros. Já o TOON tenta resolver isso declarando os campos uma vez e depois listando apenas os valores.

A própria documentação oficial destaca esse comportamento em tabular arrays, nos quais arrays uniformes “colapsam” em tabelas compactas.

A lógica é a seguinte.

No JSON

• Cada objeto repete "name", "category", "price" e outras chaves;
• Aspas, vírgulas, chaves e dois-pontos aparecem o tempo todo;
• O pretty-print adiciona ainda mais espaços e quebras.

No TOON

• Os campos aparecem uma vez no cabeçalho;
• Os registros viram linhas;
• A estrutura usa menos caracteres estruturais;
• O formato fica mais compacto para o tokenizador em vários cenários.

Essa diferença é real. O problema é que ela não se distribui igualmente em qualquer tipo de dado.

Principais conclusões dos benchmarks: TOON vs. JSON

Os resultados variam, e esse é exatamente o detalhe que os defensores do TOON costumam enterrar no rodapé.

Em datasets tabulares e homogêneos, como catálogos de produtos, logs de eventos ou qualquer lista onde os mesmos campos se repetem linha após linha, o TOON reduz o consumo de tokens entre 30% e 60% comparado ao JSON. Alguns testes apontam ainda uma leve melhora de acurácia na recuperação de dados estruturados: 73,9% contra 69,7% do JSON. A explicação mais razoável é que o schema declarado uma vez no cabeçalho corta o ruído de caracteres repetitivos, e o modelo trabalha com menos ambiguidade no caminho.

Quando os dados ficam mais complexos, a história muda. Objetos profundamente aninhados, esquemas heterogêneos, estruturas que mudam de formato entre os registros, nesses casos, a vantagem do TOON some. O JSON permanece mais estável e previsível, e a economia de tokens cai para variação marginal, chegando às vezes ao mesmo patamar de um JSON minificado.

Ou seja, o TOON não é um substituto geral para o JSON. É uma ferramenta com um caso de uso bem delimitado, envio de grandes massas de dados estruturados e uniformes para o modelo. Fora desse cenário, JSON minificado chega no mesmo lugar com muito menos complexidade de implementação. O ganho real existe, mas tem endereço certo.

Caso queria saber mais de forma prática, recomendo o vídeo onde o Prof. Rodrigo Tadewald, mostra se o hype do TOON faz algum sentido neste momento:

Quando o TOON vale a pena

O TOON faz mais sentido quando você precisa enviar muitos dados estruturados para o modelo e esses dados têm alta repetição de campos.

É o caso de catálogos, listas grandes de produtos, registros de eventos, logs, tabelas ou qualquer conjunto em que dezenas ou centenas de itens compartilham a mesma estrutura. Nesses cenários, o TOON consegue reduzir repetições e, com isso, aliviar custo e pressão sobre a janela de contexto.

Ele também pode ser útil quando o contexto já está muito próximo do limite e qualquer economia faz diferença.

Mas o ponto central continua sendo o mesmo: isso precisa aparecer em teste real, não apenas em benchmark genérico.

Quando o JSON continua sendo a melhor escolha

O JSON continua mais seguro quando a prioridade é compatibilidade, manutenção e simplicidade.

Se os dados são muito aninhados, se o esquema muda bastante, se a estrutura não é uniforme ou se a informação vai continuar sendo consumida por sistemas downstream, o JSON ainda tende a ser a escolha mais natural. O mesmo vale quando outras pessoas da equipe vão manter esse fluxo depois.

Além disso, o JSON continua melhor para structured outputs, parsing e integração com ferramentas. Hoje, ele já é entendido de forma muito mais consolidada por bibliotecas, frameworks e pipelines de produção.

Ou seja, o TOON pode ser uma boa otimização de entrada, mas o JSON continua sendo o idioma padrão do resto do sistema.

Como testar TOON em Python

Se você quiser testar TOON vs. JSON no seu fluxo, já existe uma implementação em Python voltada a encode, decode e estimativa de economia.

A instalação segue esta linha:

pip install git+https://github.com/toon-format/toon-python.git

pip install git+https://github.com/toon-format/toon-python.git

E o uso básico é bem simples:

from toon_format import encode, decode, estimate_savings

data = {
    "animals": [
        {
            "name": "African Elephant",
            "category": "mammal",
            "habitat": "savanna",
            "diet": "herbivore",
        },
        {
            "name": "Great White Shark",
            "category": "fish",
            "habitat": "ocean",
            "diet": "carnivore",
        },
    ]
}

toon_data = encode(data)
print(toon_data)

result = estimate_savings(data)
print(result)

from toon_format import encode, decode, estimate_savings

data = {
    "animals": [
        {
            "name": "African Elephant",
            "category": "mammal",
            "habitat": "savanna",
            "diet": "herbivore",
        },
        {
            "name": "Great White Shark",
            "category": "fish",
            "habitat": "ocean",
            "diet": "carnivore",
        },
    ]
}

toon_data = encode(data)
print(toon_data)

result = estimate_savings(data)
print(result)

O ponto mais importante aqui não é a conversão em si. É a medição.

Antes de decidir que o TOON vale a pena, o ideal é medir o ganho no seu conjunto de dados, com o tokenizador e o modelo que você realmente usa.

Como decidir entre TOON e JSON no seu projeto

A forma mais segura de decidir entre TOON e JSON não é confiar em benchmark genérico. É olhar para o seu caso real.

Se o seu sistema trabalha com dados estruturados grandes, repetitivos e enviados com frequência para o modelo, o TOON merece teste. Se você está lidando com catálogos extensos, grandes blocos de logs, tabelas ou listas uniformes, ele pode trazer uma economia relevante de tokens sem comprometer a estrutura da informação.

Agora, se o seu fluxo depende muito de compatibilidade entre sistemas, parsing downstream, manutenção por outras pessoas da equipe ou estruturas mais heterogêneas, o JSON continua sendo a escolha mais segura. E, antes de pensar em trocar de formato, vale fazer a pergunta mais simples de todas: você já está usando JSON minificado?

Na prática, a decisão costuma seguir uma lógica bem direta. Se o problema é só desperdício de espaços, quebras de linha e indentação, minificar o JSON já pode resolver boa parte da dor. Se, mesmo com isso, o volume de dados ainda estiver pesando no custo ou no contexto do modelo, aí sim o TOON passa a fazer mais sentido como experimento.

A melhor abordagem costuma ser incremental: manter o sistema e a comunicação interna em JSON, minificar onde possível e testar TOON apenas na camada de inferência, onde a economia realmente importa. Assim, você reduz atrito, preserva compatibilidade e só adiciona complexidade nova quando o ganho justifica.

No fim, a decisão entre TOON e JSON não deveria ser ideológica. Ela deveria ser prática. O melhor formato é o que reduz custo sem piorar manutenção, e isso só aparece quando você mede no seu próprio fluxo.

Onde aprender a construir aplicações de IA de verdade

Se você quer ir além da teoria e aprender a criar aplicações com inteligência artificial de forma mais robusta, a Formação Engenheiro de Agentes de IA da Asimov Academy é o próximo passo mais natural.

Ela é um programa completo para quem quer aprender a construir agentes inteligentes do zero, usando Python e frameworks avançados.

Ao longo da formação, você passa pelos fundamentos de lógica e Python e avança para o uso do Agno, framework voltado à criação de agentes com memória de longo prazo, raciocínio estruturado e integração com APIs, bancos de dados e mais de 20 LLMs, como ChatGPT e Claude.

Além disso, a formação cobre:

• Criação de agentes autônomos;
• Times de agentes colaborativos;
• Aplicações com LangChain;
• Projetos com RAG;
• Projetos reais para portfólio.

São cerca de 36 horas de conteúdo, com foco em performance, flexibilidade e construção de aplicações práticas.

Formação Engenheiro de Agentes de IA

Domine os frameworks de criação de agentes de IA mais avançados da atualidade e aprenda a transformar qualquer LLM em um agente!

Comece agora

FAQ: dúvidas comuns sobre TOON vs. JSON

TOON substitui JSON?

Não. O TOON foi pensado como uma opção mais compacta para prompts com LLMs, não como substituto geral do JSON em APIs e sistemas.

TOON sempre usa menos tokens?

Não necessariamente. Ele costuma ganhar de JSON formatado para leitura humana, mas a diferença pode cair bastante quando a comparação é feita com JSON minificado.

Vale usar TOON em saída de LLM?

Hoje, o caso mais claro continua sendo a entrada. Para saída parseável, o JSON ainda é mais seguro e mais natural.

TOON vale a pena em qualquer projeto com LLM?

Não. Ele faz mais sentido quando há muitos dados estruturados e repetitivos. Em prompts curtos ou instruções simples, o ganho pode ser pequeno demais para justificar a troca.