Reparador de JSON

JSON malformado é texto que parece JSON mas viola a especificação estrita da sintaxe JSON — por exemplo, chaves sem aspas, aspas simples em vez de aspas duplas, vírgulas finais, parênteses retos em falta ou comentários. Parsers estritos como o JSON.parse rejeitam-no, mas uma ferramenta de reparação geralmente consegue corrigi-lo automaticamente.

Sim. A saída de LLM é uma das fontes mais comuns de JSON corrompido. A ferramenta trata chaves sem aspas, aspas simples, vírgulas finais, parênteses retos em falta, prosa à volta do JSON e respostas truncadas (cortadas).

Não. O algoritmo de reparação corre inteiramente no seu navegador. O seu JSON nunca sai do seu dispositivo, o que torna a ferramenta segura para registos confidenciais, payloads de API e dados de clientes.

Um JSON Formatter só funciona com JSON já válido — aplica pretty-print e valida. O JSON Repair vai um passo mais longe: corrige primeiro o JSON inválido (aspas, vírgulas, parênteses retos, texto truncado) e depois produz JSON limpo e formatado. Utilize o formatador para entradas válidas e a ferramenta de reparação para entradas corrompidas.

Na maioria dos casos, sim. JSON truncado (por exemplo, um objeto cortado a meio de um valor por um limite de tokens) é reparado fechando as strings, arrays e objetos abertos. Os dados que nunca foram transmitidos não podem ser recuperados, mas a estrutura volta a ficar válida.

Falhas recuperáveis comuns: vírgulas finais, aspas simples em vez de aspas duplas, chaves sem aspas, literais True/False/None ao estilo Python, quebras de linha sem escape dentro de cadeias de caracteres e comentários. O motor de reparação reescreve-os em JSON estrito conforme a RFC 8259 e indica exatamente que correções foram aplicadas.

Cada reparação preserva a semântica sempre que possível - os comentários são removidos (o JSON não tem sintaxe de comentários) e o estilo de aspas é normalizado, mas os valores, a estrutura e a ordem mantêm o mesmo significado byte a byte. A vista de diff mostra cada transformação, para que possa confirmar que nada inesperado mudou antes de utilizar o resultado.

As três maiores fontes são o output de LLMs (os modelos emitem aspas simples, vírgulas finais e chaves sem aspas apesar das instruções), ficheiros de configuração editados à mão e registos de API truncados. Reparar antes de fazer o parsing permite que as pipelines continuem, em vez de um lote inteiro falhar por causa de um único registo malformado.