Minificação vs. embelezamento de JSON: quando usar cada uma

O que muda entre os dois

A minificação remove todo byte que não altera o significado: espaços após dois-pontos e vírgulas, quebras de linha e indentação. O embelezamento (também chamado de beautification) devolve esses espaços num padrão consistente, em geral 2 ou 4 espaços por nível de aninhamento, para você enxergar a estrutura de relance.

// Minified (48 bytes)
{"user":{"id":7,"active":true,"tags":["a","b"]}}

// Prettified (2-space indent, 96 bytes)
{
  "user": {
    "id": 7,
    "active": true,
    "tags": ["a", "b"]
  }
}

Ambos são analisados para o mesmo objeto em memória. Os 48 bytes extras da versão embelezada servem à legibilidade humana e não carregam informação semântica.

Quando a minificação é a escolha certa

Respostas e requisições de API: cada byte removido é um byte que o cliente não baixa. Num payload grande, como uma lista paginada com centenas de registros, a minificação pode cortar 15-25% do tamanho da transferência antes de a compressão entrar em ação.

Configuração embutida em HTML ou bundles JS: um blob JSON minificado inline numa tag <script> não incha seu bundle com formatação de que nenhum navegador precisa.

Linhas de log e armazenamento: se você grava JSON num arquivo de log ou numa coluna de banco, um registro por linha, minificar mantém cada registro numa única linha, e ferramentas como grep, jq -c e log shippers baseados em linha dependem disso.

Uma ressalva: se você já serve as respostas com compressão gzip ou brotli (a maioria das APIs faz isso), a economia de bytes da minificação encolhe bastante, porque espaços em branco repetidos comprimem muito bem. Minifique para os casos sem compressão (configs embutidas, logs), onde ela mais ajuda.

Quando o embelezamento é a escolha certa

Qualquer coisa que uma pessoa vá ler: exemplos de documentação de API, arquivos de configuração que desenvolvedores editam à mão (package.json, tsconfig.json), saídas de depuração e diffs de code review. Um blob JSON minificado numa linha aparece num diff do git como uma única linha alterada, por menor que seja a mudança, enquanto o JSON embelezado dá um diff limpo por linha para revisar.

Configuração sob controle de versão: indentação de 2 ou 4 espaços com uma chave por linha significa que o git consegue mostrar exatamente qual chave mudou, em vez de marcar o blob inteiro como modificado.

2 espaços vs. 4 espaços vs. tabs

JSON.parse() ignora a indentação, então a escolha não tem efeito funcional. 2 espaços é a convenção mais comum nos ecossistemas JavaScript/TypeScript (npm, a maioria dos style guides de JS) e impede que objetos muito aninhados fujam da tela. 4 espaços aparece mais em ferramentas próximas do Python. Tabs são raros em JSON, porque editores e visualizadores de diff os exibem de forma inconsistente. Escolha um e mantenha no projeto inteiro, já que indentação mista gera diffs ruidosos.