Reparar JSON roto
Convierta unos datos casi correctos en datos que un programa acepta: en el ejemplo, un registro con nombres sin comillas, comillas simples y dos comas sobrantes vuelve limpio, con el nombre Ada y las etiquetas a y b. Paga por uso, sin suscripción.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
comas, comillas, salidas de LLM
Por qué se rechazan unos datos casi correctos
Los datos que aparecen en el trabajo real rara vez están impecables. Una configuración editada a mano conserva una coma final, un fragmento copiado de un script usa comillas simples, los nombres se escriben sin comillas y la respuesta de un asistente de IA llega envuelta en marcas de bloque de código. Un lector estricto rechaza el documento entero en todos estos casos, aunque a cada uno le separe de ser válido un único arreglo pequeño y mecánico. Corregirlos a mano es lento y fácil de hacer mal cuando el texto es largo o llega muchas veces al día.
Qué hace la reparación y qué conviene revisar
La reparación quita las marcas de bloque de código, elimina las comas que quedan antes de un cierre, cambia las comillas simples por dobles y pone comillas a los nombres que no las tienen. Si los datos están dentro de otro texto, extrae el bloque y deja constancia de ello. En el ejemplo, un registro con nombres sin comillas, comillas simples y dos comas sueltas vuelve como datos limpios con el nombre Ada y una lista de dos etiquetas. Cuando el texto no tiene arreglo, se le avisa en lugar de darle una suposición. Como cada comilla simple pasa a ser doble, revise los valores que llevaban un apóstrofo, como algunos apellidos.
Preguntas frecuentes
¿Qué tipos de errores puede corregir?
Los pequeños descuidos habituales: una coma olvidada antes de un cierre, comillas simples donde van dobles, nombres escritos sin comillas y las marcas de bloque de código con que un asistente suele envolver su respuesta. El ejemplo muestra los tres primeros arreglados de una vez.
¿Qué pasa si el texto no se puede reparar?
Recibe un aviso claro de que la reparación falló, en lugar de un resultado adivinado. Eso suele indicar que el daño va más allá de los descuidos de puntuación habituales y que el texto necesita que lo revise una persona antes de usarlo.
¿Por qué se rechazan a menudo los datos que escribe un asistente de IA?
Porque los asistentes tienden a envolver los datos en marcas de bloque de código por costumbre o a usar comillas que un lector estricto no admite. La reparación quita esas marcas y corrige comillas y comas, de modo que la respuesta puede ir directa a su programa.
¿Cómo sé si mi texto se reparó de verdad?
El resultado llega como datos limpios junto con una marca de que se reparó. Si hubo que extraer los datos de un texto que los rodeaba, como una explicación antes o después, también se indica, para que compruebe que no quedó fuera nada importante.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/data/json-repair \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"json":"{name: '\''Ada'\'', tags: ['\''a'\'','\''b'\'',],}"}'const res = await fetch("https://api.kit.forhosting.com/data/json-repair", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"json": "{name: 'Ada', tags: ['a','b',],}"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/data/json-repair",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"json": "{name: 'Ada', tags: ['a','b',],}"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/data/json-repair", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"json":"{name: \'Ada\', tags: [\'a\',\'b\',],}"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"json":"{name: 'Ada', tags: ['a','b',],}"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/data/json-repair", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"json": "{name: 'Ada', tags: ['a','b',],}"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "data.json_repair",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
max_mb | 25 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
422 | task_failed | La tarea falló tras 3 reintentos. No se cobra. |
Notas técnicas
El JSON que realmente aparece en producción rara vez es el tipo limpio y perfecto según la especificación: trae una coma final de una configuración editada a mano, comillas simples copiadas de JavaScript, o quedó cortado a la mitad de un objeto porque un modelo de lenguaje llegó a su límite de tokens. Este endpoint toma ese texto roto y lo repara hasta convertirlo en JSON que un analizador estricto acepte.
Por qué el 'casi JSON' está en todas partes ahora
Desde que los modelos de lenguaje empezaron a generar salidas estructuradas como texto plano en lugar de mediante un esquema garantizado, buena parte del JSON que circula por los pipelines de automatización hoy viene de un modelo que se cortó a mitad de la respuesta, agregó un comentario suelto o envolvió el objeto en marcado de markdown por costumbre. Sume JSON editado a mano por alguien acostumbrado a los literales de objeto flexibles de JavaScript, o archivos de configuración copiados entre proyectos con una coma final sobrante, y un analizador estricto termina rechazando documentos que están a un arreglo pequeño y mecánico de ser perfectamente válidos. data.json_repair existe exactamente para esa brecha entre 'evidentemente pretendía ser JSON' y 'pasa JSON.parse'.
Qué se arregla y cómo lo recibe de vuelta
Maneja directamente los patrones de falla más comunes: comas finales antes de un corchete de cierre, claves sin comillas o con comillas simples, corchetes de cierre faltantes por un flujo cortado a la mitad, y texto suelto como los bloques de markdown envolviendo el objeto. Envíe el texto roto por POST a /data/json-repair, y recibirá un task_id de inmediato mientras la reparación corre en segundo plano. El JSON reparado y estrictamente válido —junto con un resumen de lo que se cambió— llega por webhook firmado o queda disponible en un enlace firmado válido por 24 horas.
Reparar frente a adivinar
No fabrica valores de campos faltantes ni adivina qué debía decir un valor truncado; si un valor en sí quedó cortado sin forma de recuperarlo, eso se reporta en lugar de inventarse, porque una herramienta de reparación que inventa datos en silencio es peor que una que falla ruidosamente. Hay una línea importante entre corregir la sintaxis estructural e inventar datos, y este endpoint se mantiene firmemente del lado de la sintaxis: cerrar una cadena de texto sin terminar, agregar un corchete faltante, quitar una coma que no debería estar ahí son correcciones mecánicas y sin ambigüedad.
Dónde encaja en un pipeline automatizado
El lugar natural para este endpoint es justo después de cualquier paso que produzca JSON sin garantía estricta de estar bien formado —analizar la respuesta de un modelo de lenguaje, ingresar una configuración mantenida a mano, o leer la salida de un script que no valida lo que escribe— y justo antes de que ese JSON llegue a código que de otro modo fallaría en el primer error de sintaxis. Como el precio es por solicitud más una tarifa por documento y un fallo nunca se cobra, resulta lo bastante económico como para correr como red de seguridad permanente sobre cada payload que recibe un pipeline.
Casos de integración
Recuperar respuestas de LLM cortadas
Un pipeline de agentes repara la salida JSON de un modelo de lenguaje que se cortó a mitad de un objeto por alcanzar su límite de tokens, recuperando todo lo que se transmitió antes del corte.
Limpiar archivos de configuración editados a mano
Una herramienta de DevOps repara archivos de configuración JSON editados a mano que quedaron con comas finales o claves con comillas simples por costumbres de JavaScript.
Quitar bloques de markdown de la salida de un modelo
Un script de automatización repara JSON que un modelo de chat envolvió en bloques de markdown de triple comilla invertida, extrayendo y validando el objeto interior.
Filtro de validación antes de la ingesta
Un pipeline de datos pasa cada payload JSON entrante por reparación antes de almacenarlo, para que un problema menor de sintaxis nunca bloquee un registro que de otro modo sería utilizable.
Preguntas técnicas
¿Cómo arreglo JSON roto con la API?
Envíe el texto mal formado por POST a /data/json-repair, guarde el task_id devuelto y reciba el JSON reparado por webhook o mediante un enlace firmado válido por 24 horas.
¿Es gratis la API para reparar JSON?
No, no hay plan gratuito ni prueba; cuesta $0.003 por solicitud más $0.0135 por documento, y una reparación fallida nunca se cobra.
¿Puede arreglar JSON truncado por un LLM que llegó a su límite de tokens?
Sí, cerrar cadenas de texto, objetos y arreglos sin terminar por un flujo cortado es una de las reparaciones más comunes que realiza.
¿Arregla comas finales y claves con comillas simples?
Sí, las comas finales antes de corchetes de cierre y las claves sin comillas o con comillas simples, comunes en JSON editado a mano o al estilo JavaScript, se corrigen.
¿Inventa datos faltantes para que el JSON quede válido?
No, solo corrige la sintaxis estructural; si un valor real quedó truncado sin forma de recuperarlo, eso se reporta en lugar de fabricarse.
¿Quita los bloques de markdown alrededor del JSON?
Sí, el JSON envuelto en bloques de markdown de triple comilla invertida, común en salidas de modelos de chat, se desenvuelve y valida como parte de la reparación.
¿Puedo reparar un lote grande de documentos a la vez?
Sí, envíe una tarea asíncrona por documento y reciba cada resultado por webhook, lo cual funciona bien para pipelines que reparan muchas salidas de LLM o configuraciones a la vez.
¿Se guardan mis datos JSON rotos después de la reparación?
No, el texto enviado y los resultados reparados se eliminan después del período de retención y nunca se usan para entrenamiento.