JSON formatado não significa necessariamente dados corretos
A indentação facilita inspecionar configurações ou uma resposta de serviço. Não informa se o preço está certo, se um campo é obrigatório ou se a medida usa a unidade adequada.
Sintaxe é a primeira verificação, não a última
JSON usa aspas duplas em textos e nomes de propriedades. Comentários e vírgula depois do último elemento não pertencem à sintaxe padrão.
Depois da leitura, confira o contrato: campos obrigatórios, tipos, unidades e valores aceitos. quantity como texto pode ser JSON válido, mas inadequado para um serviço que espera número.
Referências: RFC 8259 — JSON syntax and interoperability
Espaço dentro de uma string é dado
Espaços ao redor da pontuação estrutural podem mudar sem alterar a estrutura. Dentro de aspas fazem parte do valor; minificar não significa apagar todo espaço.
ToolRoof preserva a notação original dos números e textos. Formatar não transforma o identificador "0042" no número 42 nem reescreve 1e3 só para mudar a aparência.
Referências: RFC 8259 — JSON syntax and interoperability
Chaves repetidas pedem uma decisão separada
O padrão recomenda nomes únicos no objeto porque programas tratam duplicatas de modo diferente. Uma formatação bem-sucedida não revela qual valor era o pretendido.
Resolva duplicatas na origem segundo o contrato, sem presumir que o último valor sempre vence. Preservar um número grande aqui também não garante a mesma precisão em outro sistema.
Referências: RFC 8259 — JSON syntax and interoperability
Exemplo: caixa com código, não número para cálculo
Em {"item":"box blue","quantity":2,"amount":1e3,"code":"0042"}, o nome tem 2 espaços, quantity é número, amount usa expoente e code é texto com 2 zeros iniciais. A indentação não deve apagar essas diferenças.
Minificar mantém os 2 espaços de box blue, a notação 1e3 e a string "0042". Já {"count":2,"count":3} exige uma decisão nos dados de origem: a apresentação mais bonita não define a contagem pretendida.