Tu llamada a la API acaba de fallar con JSONDecodeError: Expecting property name enclosed in double quotes. El reloj corre. Los datos venían de un LLM y, en algún punto de esa respuesta de 2000 tokens, una sola coma final ha matado toda tu pipeline.
A mayo de 2026, la forma más rápida de reparar archivos JSON mal formados es usar librerías automatizadas como json_repair (Python) o jsonrepair (npm). Estas herramientas están diseñadas específicamente para corregir al instante los errores de sintaxis generados por los LLM. Para las reparaciones manuales, los sospechosos habituales son las comas finales, las comillas simples o las claves sin comillas: las tres violaciones más comunes del estándar RFC 8259.
La solución más rápida: json_repair para salidas de LLM
Los parseadores estándar como json.loads() de Python son estrictos por diseño. Un solo carácter mal colocado dispara un JSONDecodeError y todo se detiene. Este es un problema cotidiano en 2026, porque los LLM envuelven habitualmente el JSON en texto conversacional, truncan respuestas a mitad de frase o esparcen comentarios que rompen la especificación.
La librería json_repair es la solución de referencia. Según GitHub, este proyecto acumula más de 4700 estrellas a 2026. Funciona «adivinando» la intención de la cadena: cierra llaves faltantes, añade comillas y elimina el texto sobrante que rodea al bloque JSON.
Python: antes y después
Instalación: pip install json-repair
La entrada rota:
import json_repair
bad_json = '{"user": "Alice", "status": tru'
decoded_object = json_repair.loads(bad_json)
Lo que ocurrió entre bastidores: json_repair detectó que tru probablemente era true, añadi la llave de cierre faltante y devolvió un diccionario de Python válido. Cero intervención manual.
Modo Salvage: cuando los datos están realmente feos
Para los casos más difíciles, json_repair (v0.59.5+) incluye un Modo Salvage. Como se indica en la documentación del proyecto, este modo está construido específicamente para respuestas de IA truncadas o logs corruptos. Puede forzar arrays a objetos o descartar elementos demasiado dañados para salvar, garantizando que la salida se ajuste a tu esquema.
import json_repair
# Salvage mode for severely truncated data
result = json_repair.loads(
'{"items": [{"id": 1, "name": "Widget"}, {"id": 2, "na',
salvage_mode=True
)
# Result: {'items': [{'id': 1, 'name': 'Widget'}, {'id': 2}]}
# Dropped the incomplete 'na' but saved everything else
Alternativa con npm
Para proyectos Node.js, el CLI jsonrepair hace el mismo trabajo:
# Fix a file in place
npx jsonrepair broken.json > fixed.json
# Fix a string in a script
const { jsonrepair } = require('jsonrepair');
const fixed = jsonrepair('{"name": "test",}');
Depuración manual: encontrar qué rompió la especificación
Cuando la automatización no basta, necesitas encontrar exactamente dónde el archivo viola RFC 8259. JSON es mucho menos indulgente que YAML o JavaScript. Como explica el equipo de diagnóstico de JSONParser: «El parser falla en el primer carácter que no logra interpretar, lo cual suele ser un síntoma posterior de un problema originado varias líneas antes».
Los tres asesinos del JSON
Asesino 1: comas finales
Según la DEV Community, las comas finales son la causa número 1 de fallos de parseo. Son válidas en JavaScript, pero ilegales después del último elemento de un array u objeto JSON.
// BROKEN - trailing comma after "active"
{
"name": "Alice",
"status": "active",
}
// FIXED - no comma before closing brace
{
"name": "Alice",
"status": "active"
}
Asesino 2: comillas simples
JSON exige comillas dobles (") tanto para claves como para valores de cadena. Muchos desarrolladores de Python y JavaScript usan por accidente comillas simples ('). Como señala TidyCode, esto es una corrección obligatoria.
// BROKEN - single quotes
{'name': 'Alice'}
// FIXED - double quotes
{"name": "Alice"}
Asesino 3: claves sin comillas
En JavaScript puedes escribir { name: "Alice" }. En JSON, cada clave necesita comillas dobles.
// BROKEN - unquoted key
{name: "Alice"}
// FIXED - quoted key
{"name": "Alice"}
El error «Unexpected Token»
Cuando un validador marca «Unexpected Token», significa que el parser se topó con NaN, Infinity o undefined: constantes de JavaScript que JSON no admite. JSON solo permite null, true, false y números.
// BROKEN - NaN is not valid JSON
{"score": NaN, "result": Infinity}
// FIXED - replace with null or valid values
{"score": null, "result": null}
Parseo estricto vs. parseo de reparación: cuándo usar cada uno
El enfoque correcto depende del origen de tus datos. Los archivos de configuración editados por humanos merecen un parseo estricto que obligue al autor a corregir los errores. Los datos generados por máquinas, provenientes de LLM o logs de API, necesitan un parseo basado en reparación.
| Característica | Estricto (json.loads) |
Reparación (json_repair) |
|---|---|---|
| Comas finales | Lanza JSONDecodeError |
Se eliminan automáticamente |
| Comillas simples | Falla | Se convierten a comillas dobles |
| Datos truncados | Falla | Cierra llaves/comillas abiertas |
| Comentarios | Falla | Se eliminan automáticamente |
| Caso de uso ideal | Archivos de configuración editados por humanos | Salidas de LLM, logs de API |
Reparaciones guiadas por esquema con Pydantic
Puedes guiar el proceso de reparación usando Pydantic v2 o JSON Schema. Al proporcionar a json_repair un esquema, la herramienta hace más que corregir sintaxis: puede corregir tipos (convertir la cadena "1" en el número 1) y rellenar campos obligatorios ausentes con valores por defecto.
from pydantic import BaseModel
import json_repair
class User(BaseModel):
id: int
name: str
active: bool = True
# Broken JSON with wrong types
raw = '{"id": "42", "name": "Alice"}'
repaired = json_repair.loads(raw)
# Validate against schema
user = User(**repaired)
# user.id is now int(42), user.active defaults to True
Como señaló Stefano Baccianella en la cita de su proyecto de 2025, este enfoque está optimizado para el JSON «mayoritariamente correcto pero técnicamente inválido» que los modelos de lenguaje tienden a producir.
Manejar archivos de varios gigabytes sin caerse
Reparar un fragmento de 10 KB es fácil. Arreglar un archivo de 2 GB requiere una estrategia que no devore toda tu RAM. Cargar el archivo entero en memoria provoca errores de memoria agotada (OOM).
Estrategia 1: streaming con ijson
Para conjuntos de datos masivos, usa ijson para procesar la información pieza a pieza. Como menciona Scrapfly, ijson procesa los datos de forma incremental. Combínalo con un script de limpieza que corrija problemas línea a línea antes del parseo.
import ijson
# Stream through a large JSON file
with open('huge_broken.json', 'r') as f:
for item in ijson.items(f, 'records.item'):
# Process each item individually
process(item)
Estrategia 2: tubería CLI para máxima eficiencia
El enfoque más eficiente en memoria para archivos grandes es usar el CLI jsonrepair y enviar la salida directamente a un archivo nuevo:
# Streams repair, never loads full file into memory
jsonrepair large_broken.json > fixed.json
Esto es notablemente más eficiente en memoria que cargar el archivo en Python o en un navegador.
Conclusión
Reparar JSON mal formado ya no es una tarea manual gracias a librerías conscientes de la IA como json_repair. Aún necesitas conocer los fundamentos de RFC 8259: sin comas finales, sin comillas simples, sin claves sin comillas, pero la automatización es el único enfoque práctico para los datos a escala en 2026.
El flujo de trabajo es sencillo: prueba primero una librería de reparación. Si falla, usa un validador para localizar el error de sintaxis exacto. Así mantienes tus aplicaciones en marcha incluso cuando los datos entrantes son menos que perfectos.
Preguntas frecuentes
¿Admite JSON oficialmente comentarios o comillas simples?
No. El estándar RFC 8259 prohíbe estrictamente los comentarios. Las comillas simples también son inválidas: solo se permiten comillas dobles para claves y cadenas. Sin embargo, herramientas como json_repair pueden eliminar comentarios y convertir comillas automáticamente para que los archivos sean parseables por librerías estándar.
¿Cómo manejo archivos JSON mal formados muy grandes sin caerme?
Usa un parser de streaming como ijson para procesar los datos en bloques. Evita cargar la cadena mal formada entera en una sola variable. Para los resultados más rápidos, usa herramientas de reparación por CLI que envíen la salida directamente a un archivo nuevo en disco sin mantener todo en memoria.
¿Cuál es la diferencia entre JSON mal formado y JSON inválido?
El JSON mal formado (malformed) viola las reglas de sintaxis (llaves faltantes, claves sin comillas, comas finales) y por tanto es imposible de parsear. El JSON inválido (invalid) cumple todas las reglas de sintaxis, pero no coincide con un JSON Schema concreto (por ejemplo, un campo es una cadena cuando el esquema espera un entero). Reparar JSON mal formado es reparación estructural; reparar JSON inválido es cuestión de integridad de datos.
¿Puedo usar json_repair con validación de Pydantic?
Sí. Ejecuta primero json_repair.loads() para corregir los errores de sintaxis y luego pasa el diccionario reparado a tu modelo Pydantic para validación de tipos y aplicación del esquema. Este enfoque en dos pasos cubre tanto los problemas estructurales como los semánticos.
¿Qué pasa con JSON que lleva comentarios estilo JavaScript?
El JSON estándar no admite comentarios, pero json_repair puede eliminar automáticamente los comentarios // y /* */. Si necesitas comentarios en tus archivos de configuración, considera usar el formato JSONC (JSON con comentarios) y un parser compatible como json5 para Python.
