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

O que realmente 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) adiciona esses espaços de volta num padrão consistente — geralmente 2 ou 4 espaços por nível de aninhamento — para que um humano consiga 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 exatamente o mesmo objeto em memória. Os 48 bytes extras da versão embelezada existem puramente para legibilidade humana — carregam zero 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 — uma lista paginada com centenas de registros — a minificação pode cortar 15-25% do tamanho da transferência antes mesmo da compressão rodar.

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ê está gravando JSON num arquivo de log ou numa coluna de banco, um registro por linha, a versão minificada mantém cada registro numa única linha — o que importa para ferramentas como grep, jq -c e log shippers baseados em linha.

Uma ressalva: se suas respostas já são servidas com compressão gzip ou brotli (a maioria das APIs é), a economia de bytes da minificação encolhe bastante — espaços em branco repetidos comprimem extremamente bem. Minifique para o caso não comprimido (configs embutidas, logs), onde ela mais importa.

Quando o embelezamento é a escolha certa

Qualquer coisa que um humano vai 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 mostra-se num diff do git como uma única linha alterada, por menor que seja a mudança real — o JSON embelezado mostra um diff limpo e revisável no nível de linha.

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

Não há diferença funcional — JSON.parse() ignora isso completamente. 2 espaços é a convenção mais comum nos ecossistemas JavaScript/TypeScript (npm, a maioria dos style guides de JS) e impede que objetos profundamente aninhados fujam da tela. 4 espaços é mais comum em ferramentas próximas do Python. Tabs são raros para JSON especificamente, pois renderizam de forma inconsistente entre editores e visualizadores de diff. Escolha um e mantenha a consistência dentro do projeto — indentação mista em JSON é uma fonte comum de diffs ruidosos.