Reparación de JSON

El JSON malformado es texto que parece JSON pero viola la especificación estricta de la sintaxis JSON — por ejemplo, claves sin comillas, comillas simples en lugar de dobles, comas finales, corchetes faltantes o comentarios. Los parsers estrictos como JSON.parse lo rechazan, pero una herramienta de reparación normalmente puede corregirlo automáticamente.

Sí. La salida de los LLM es una de las fuentes más comunes de JSON roto. La herramienta maneja claves sin comillas, comillas simples, comas finales, corchetes faltantes, prosa alrededor del JSON y respuestas truncadas (cortadas).

No. El algoritmo de reparación se ejecuta completamente en tu navegador. Tu JSON nunca sale de tu dispositivo, lo que hace que la herramienta sea segura para registros confidenciales, payloads de API y datos de clientes.

Un JSON Formatter solo funciona con JSON ya válido — lo embellece y valida. JSON Repair va un paso más allá: primero corrige el JSON inválido (comillas, comas, corchetes, truncamiento) y luego genera JSON limpio y formateado. Usa el formateador para entradas válidas y la herramienta de reparación para entradas rotas.

En la mayoría de los casos, sí. El JSON truncado (por ejemplo, un objeto cortado a mitad de un valor por un límite de tokens) se repara cerrando las cadenas, arrays y objetos abiertos. Los datos que nunca se transmitieron no se pueden recuperar, pero la estructura vuelve a ser válida.

Fallos recuperables comunes: comas finales, comillas simples en lugar de comillas dobles, claves sin comillas, literales True/False/None al estilo de Python, saltos de línea sin escapar dentro de cadenas y comentarios. El motor de reparación los reescribe como JSON estricto conforme a RFC 8259 e informa exactamente qué correcciones se aplicaron.

Cada reparación preserva la semántica siempre que sea posible - los comentarios se descartan (JSON no tiene sintaxis de comentarios) y el estilo de comillas se normaliza, pero los valores, la estructura y el orden se conservan con el mismo significado byte a byte. La vista de diff muestra cada transformación para que puedas verificar que nada inesperado cambió antes de usar el resultado.

Las tres fuentes principales son la salida de los LLM (los modelos emiten comillas simples, comas finales y claves sin comillas a pesar de las instrucciones), los archivos de configuración editados a mano y los registros de API truncados. Reparar antes de parsear permite que los pipelines continúen en lugar de que falle un lote completo por un único registro mal formado.