Por que uma vírgula sobrando no final de um array é aceita em JavaScript mas rejeitada em JSON?

Porque JSON é definido por uma gramática formal mais restrita (RFC 8259) do que a sintaxe de objeto literal do JavaScript, que evoluiu para aceitar trailing commas por conveniência de edição. JSON manteve a regra original, sem essa permissão — um parser JSON estrito rejeita a vírgula sobrando mesmo que o mesmo código funcione como objeto JavaScript.

Chaves de objeto sem aspas, como {nome: "valor"}, são JSON válido?

Não. JSON exige que toda chave de objeto esteja entre aspas duplas — {"nome": "valor"}. A versão sem aspas é sintaxe de objeto literal do JavaScript, válida nessa linguagem, mas não atende à gramática formal do JSON definida pela RFC 8259.

Minificar um JSON muda a estrutura de dados que ele representa?

Não. Minificar remove apenas espaços em branco desnecessários (indentação, quebras de linha) para reduzir o tamanho do arquivo transmitido — JSON.parse() produz exatamente o mesmo objeto a partir da versão minificada e da formatada. São duas representações textuais equivalentes do mesmo dado.

Formatador de JSON Online

Documentação técnica

Formatador de JSON: por que "quase JSON" não é JSON

JSON tem uma gramática formal definida pela RFC 8259 — mais restrita do que muita gente assume, justamente por JSON ter nascido como um subconjunto da sintaxe de objeto literal do JavaScript. Isso cria uma armadilha comum: código que parece válido porque "é JavaScript válido" frequentemente não é JSON válido. As três violações mais comuns que este formatador detecta e que costumam surpreender quem vem de JavaScript: vírgula sobrando depois do último item de um array ou objeto (trailing comma, permitida em JS moderno, proibida em JSON), aspas simples em vez de aspas duplas para strings (JSON exige aspas duplas, sem exceção), e chaves de objeto sem aspas ({nome: "valor"} é JS válido, mas não JSON — precisa ser {"nome": "valor"}).

Por que a validação de formato importa antes do parse

Um JSON.parse() que falha por sintaxe inválida geralmente aponta a posição exata do erro, mas em um payload grande (uma resposta de API complexa, um arquivo de configuração extenso) encontrar visualmente aquele ponto específico é trabalhoso. Um formatador que reformata com indentação consistente antes de validar torna o erro fácil de localizar visualmente — a mesma razão pela qual "formatar e depois revisar" é mais produtivo do que tentar ler JSON minificado numa única linha para achar um erro de sintaxe.

Minificar não é o oposto de formatar, é um objetivo diferente

Minificar JSON (remover todo espaço em branco desnecessário) reduz o tamanho do payload transmitido — relevante para APIs de alto volume ou payloads que trafegam por conexões com latência ou banda limitada — mas não altera a estrutura de dados em nenhum aspecto semântico: um JSON.parse() produz exatamente o mesmo objeto a partir da versão formatada e da minificada. São duas representações textuais do mesmo dado, cada uma otimizada para um objetivo diferente: legibilidade humana versus tamanho de transmissão.