Validador de sintaxis JSON

1. 1Pegue o suba JSONPegue su JSON en el editor, o arrastre un archivo .json, .jsonc, .json5, .ndjson, .geojson o .webmanifest sobre el área de soltar. Funciona tanto minificado como formateado, y nada se sube a ningún servidor.
2. 2Pulse ValidarCada error de sintaxis aparece a la vez con su línea, columna y desplazamiento en bytes, y un cursor que marca el carácter exacto. Si el JSON es válido verá en su lugar el tipo raíz, el tamaño y la estructura.
3. 3Lea también los avisosLas claves duplicadas y los números que pierden precisión son JSON legal que todos los parsers aceptan en silencio. Aparecen como avisos con un JSON Pointer a cada uno, porque son los fallos que llegan a producción.
4. 4Corríjalo, o deje que la herramienta lo hagaPulse un hallazgo para llevar el cursor hasta él. Si el texto es JSON5, JSONC o un diccionario de Python en vez de JSON roto, la herramienta lo dice y ofrece una copia reparada que puede aplicar o descargar.

Compruebe la validez de su JSON en segundos, con la ubicación exacta del error, la explicación del parser y un resumen estructural para depurar rápido. Pegue o suba JSON y pulse Validar para obtener al instante un aprobado o un fallo. Cuando es válido verá el tipo raíz, su tamaño y un informe completo de estructura. Cuando no lo es verá todos los errores a la vez —cada uno con su línea, columna, desplazamiento en bytes y un cursor bajo el carácter exacto— además de los avisos que ningún otro validador le muestra: claves duplicadas y números que cambian de valor en silencio al analizarse. Todo se ejecuta en su dispositivo, así que los payloads privados, los tokens y los esquemas internos nunca salen de él.

• Todos los errores, de una vez — Un parser se detiene en el primer fallo. Este se resincroniza y continúa, así que un archivo con cuarenta errores cuesta una pasada, no cuarenta.
• La misma ubicación en todas partes — Línea, columna, desplazamiento en bytes y un cursor, calculados a partir de los bytes en vez de extraerse de un mensaje del navegador: idénticos en Chrome, Firefox y Safari.
• Los fallos que pasan desapercibidos — Las claves duplicadas y los números que pierden precisión son JSON legal. También son la forma en que los datos desaparecen sin ruido, así que se informan como avisos.
• Esquema, dialectos y reparación — Compruebe contra un JSON Schema, descubra que su archivo en realidad es JSON5 y llévese una copia reparada en una pulsación.
• Pegar o subir — Pegue desde el portapapeles, suelte un archivo o búsquelo. Restablecer limpia la entrada y el resultado a la vez.

Lo más útil que puede decirle un validador es dónde mirar, y es justo lo que la mayoría de validadores online hacen de forma menos fiable. Reproducen lo que dice el parser integrado del navegador, y esos mensajes no son iguales en todos.

Medido en los tres motores reales: el parser de Safari informa «JSON Parse error: Expected '}'», sin posición, sin línea y sin columna. Firefox da línea y columna pero ningún desplazamiento. Solo Chrome da los tres. Un validador que lee esos mensajes con un patrón funciona bien en uno de cada tres navegadores y se degrada en silencio en los demás.

• Línea y columna — Contadas en caracteres, no en bytes, para que una línea que empieza con una palabra acentuada no indique una columna con la que su editor no esté de acuerdo.
• Desplazamiento en bytes — Lo que necesita cuando el archivo lo maneja un script y no un editor.
• Un cursor bajo el fallo — La línea afectada, con el carácter exacto marcado. En una línea larga el fragmento se recorta alrededor del fallo, no al principio.
• Un JSON Pointer — Dónde está el fallo dentro de la estructura del documento —/users/3/email— y no solo dentro del texto.

Un parser JSON existe para producir un valor, así que en cuanto encuentra algo que no puede usar lanza una excepción y se detiene. Eso es correcto en un parser y poco útil en un validador: corrige la coma que falta en la línea 12, ejecútalo otra vez, descubre la clave sin comillas de la línea 40, ejecútalo otra vez.

Este validador no está construyendo un valor, así que no tiene nada que abandonar. Cuando encuentra un símbolo que no encaja en ninguna parte registra el fallo y se resincroniza —tratando una coma ausente como si estuviera, cerrando un contenedor que encontró el corchete equivocado— y sigue hasta el final del archivo. El resultado es la lista completa en una pasada. Deja de registrar a los mil hallazgos, mucho más allá del punto en que un archivo merece corregirse a mano en vez de regenerarse.

• Separadores que faltan — Una coma o dos puntos ausentes se tratan como una errata y el análisis continúa, en vez de arrastrar un error a cada miembro siguiente.
• Corchetes cruzados — Un cierre que no corresponde a su apertura cierra el contenedor igualmente, para que un desliz no convierta el resto del archivo en ruido.
• Cadenas sin cerrar — Una cadena a la que le falta una comilla termina al final de su línea en vez de tragarse el resto del documento.

JSON permite la misma clave dos veces en un objeto. La especificación se abstiene de decir qué debería pasar, y la respuesta práctica es que todos los parsers mayoritarios se quedan con la última aparición y descartan la primera sin decir nada.

Así que un archivo de configuración con una clave puesta dos veces es válido, y la mitad no hace nada. Una respuesta de API combinada con un campo repetido es válida, y uno de los dos valores ha desaparecido. Como es legal, esto se queda en aviso y no en fallo —el veredicto tiene que coincidir con el parser que realmente consumirá el archivo—, pero se informa con un JSON Pointer a cada aparición y el desplazamiento de la primera, para que pueda ver ambas.

• Exacto, no aproximado — Las claves se comparan por su valor decodificado, así que una clave escrita como "a" y la misma escrita con un escape se reconocen correctamente como la misma clave.
• Por objeto, no por documento — La misma clave en dos objetos hermanos es normal y no se informa. Solo se informa una repetición dentro de un mismo objeto.
• A cualquier profundidad — Un duplicado veinte niveles más abajo se encuentra, con el puntero que lleva hasta él.

JSON no pone límite al tamaño ni a la precisión de un número, y casi todos los parsers los leen en coma flotante de 64 bits. Por encima de 9.007.199.254.740.991 un entero ya no se puede representar exactamente, así que se redondea, en silencio, sin error ni aviso en ningún punto de la cadena.

No es un problema teórico. Los IDs tipo Snowflake, los identificadores al estilo de Twitter, los números de pedido y los importes contables viven en ese rango, y el síntoma es un registro que no se encuentra porque su ID volvió desviado unos cientos. El validador comprueba cada literal numérico que pueda verse afectado e informa del valor exacto junto al que producirá un parser.

• Enteros grandes — Comparados con exactitud, usando aritmética de precisión arbitraria en vez del valor en coma flotante que es justo lo que está en cuestión.
• Decimales largos — Un decimal que no se puede recuperar del double en que se convierte se informa con el valor al que realmente se redondeará.
• Desbordamiento y subdesbordamiento — 1e400 se convierte en Infinity y 1e-400 en cero. Ninguno es representable en JSON, y ninguno provoca un error en ningún otro sitio.
• Barato cuando no aplica — Un literal de quince dígitos o menos no puede perder nada, así que se omite por completo. Solo se examinan los que podrían verse afectados.

Una buena parte de los archivos que se declaran «JSON inválido» no están rotos en absoluto. Están escritos en un dialecto: JSONC, que añade comentarios y comas finales, o JSON5, que además permite claves sin comillas, comillas simples, números hexadecimales y NaN. Su editor los lee sin problema; un parser estricto los rechaza.

tsconfig.json, .eslintrc y la mayoría de archivos de ajustes de editores son JSONC. Un diccionario copiado de una sesión de Python se parece a JSON pero usa True, False y None. En vez de llamar roto a nada de esto, el validador nombra lo que está mirando, enumera qué construcciones son responsables y ofrece una copia en JSON estricto.

• Comentarios — Se reconocen tanto de línea como de bloque, y solo fuera de las cadenas, así que una URL con doble barra queda intacta.
• Comas finales — Una coma antes del corchete o la llave de cierre, señalada en la coma y no en el corchete.
• Comillas y claves desnudas — Cadenas con comillas simples, claves sin comillas y las comillas tipográficas que deja un procesador de textos.
• Literales que no son JSON — NaN e Infinity, números hexadecimales, un signo más o un punto decimal iniciales, y True, False y None de Python.

Cada reparación procede de un hallazgo que el analizador ya localizó, nunca de un patrón aplicado a todo el documento. Esa distinción importa más de lo que parece: una expresión regular que quita comentarios también borra la doble barra dentro de "https://example.com", y una que quita comas finales también borra la coma dentro de "a, b,". El analizador sabe qué bytes estaban dentro de una cadena y cuáles no, así que ninguno de esos errores está a su alcance.

El documento reparado se vuelve a validar antes de ofrecerse, y si sigue sin ser válido se presenta como arreglo parcial con los fallos restantes enumerados. Un botón que dice «Arreglado» y devuelve algo que no analiza es peor que no tener botón.

• Qué se arregla — Comentarios, comas finales, comillas simples y tipográficas, claves sin comillas, números hexadecimales, un más o un punto iniciales, y True, False y None de Python.
• Qué se marca como con pérdida — NaN e Infinity no tienen forma de escribirse en JSON. Se convierten en null, y el cambio se anuncia en vez de hacerse en silencio.
• Aplicar o descargar — Ponga el texto reparado directamente en el editor, o descárguelo como archivo .json.

La sintaxis es solo la mitad de la pregunta. «¿Tiene la forma correcta?» es la otra mitad, y eso es lo que responde un JSON Schema. Pegue uno en el panel y el documento se comprueba también contra él, con cada fallo acompañado de un JSON Pointer al valor culpable y la línea en la que está.

Se admiten draft 2020-12 y draft-07, y el draft se lee de $schema —o se deduce cuando el esquema no lo declara, que es lo que ocurre con casi todos los escritos antes de 2020—. Esa deducción importa: la forma de array de items en draft-07 significa otra cosa en 2020-12, y leer una como la otra produce una respuesta segura y equivocada en vez de un error.

• El vocabulario de validación completo — type, enum, const, los límites numéricos, longitud y patrón de cadenas, restricciones de arrays y objetos, required y las palabras clave dependientes.
• Aplicadores — allOf, anyOf, oneOf, not, if/then/else, prefixItems, contains, propertyNames y tanto unevaluatedProperties como unevaluatedItems.
• Referencias — $ref, $defs, definitions, $anchor y el ámbito de $id se resuelven dentro del esquema que usted aporta. Una referencia a otro servidor se informa por su nombre y nunca se descarga.
• format, tal como lo define la especificación — Una anotación por defecto, exactamente como dicen ambos drafts: un esquema con "format": "email" no rechaza una dirección incorrecta salvo que usted lo pida. Hay un interruptor para quien esperaba lo contrario.

Un valor JSON por línea es como se escriben los pipelines de logs, las exportaciones de BigQuery, los cuerpos de API por lotes y los conjuntos de entrenamiento. Leído como un único documento JSON, un archivo así produce exactamente un error —contenido sobrante al principio de la línea dos—, que es técnicamente correcto y completamente inútil.

El modo NDJSON valida cada registro por separado, así que un fallo se informa contra el registro en el que está. El modo se propone automáticamente cuando un archivo parece delimitado por líneas, y se propone en vez de aplicarse: una herramienta que reinterpreta su entrada en silencio es una herramienta sobre la que no se puede razonar.

• Resultados por registro — Cada fallo lleva su número de registro además de su línea y columna, y se informa junto al número de registros que pasaron.
• El salto de línea final — Todo escritor termina el último registro con un salto de línea. Esa última línea vacía no es un registro, y tratarla como tal añade un error falso a casi todos los archivos bien escritos.
• Finales de línea de Windows — Un retorno de carro al final de un registro sería, si no, un carácter de control dentro de su último símbolo: un error por línea en cualquier archivo escrito en Windows.
• Registros vacíos — Una línea en blanco en medio se informa en vez de omitirse. El formato no tiene separador, así que una línea vacía significa que se escribió un registro vacío.

Un archivo puede ser JSON perfectamente correcto y aun así fallar por tres bytes invisibles. Una marca de orden de bytes UTF-8 —lo que escriben Out-File de PowerShell, StreamWriter de .NET y la exportación «UTF-8» de Excel— se coloca delante de la llave inicial, y un parser estricto informa de un símbolo inesperado en la posición 0 para un documento por lo demás impecable.

UTF-16 es peor, porque es lo que escribe Windows PowerShell cuando no se especifica codificación alguna. Leído como UTF-8 parece tener un byte NUL después de cada carácter, y el error apunta a algo que nadie puede ver. Aquí ambos se detectan y se manejan, y se informa de la codificación empleada para que nada ocurra a sus espaldas.

• UTF-8, con marca o sin ella — La marca se reconoce, se retira y se informa. El documento se valida como si nunca hubiera estado ahí.
• UTF-16, con marca o sin ella — Se detecta por la marca, o por dónde caen los bytes NUL: los caracteres estructurales de JSON son todos ASCII, así que el patrón es concluyente y no una conjetura.
• Bytes mal formados — Un byte que no es UTF-8 válido se informa como aviso, no como veredicto: un navegador lo sustituye antes de que ningún parser lo vea, así que no puede invalidar un documento, pero sí significa que el archivo no está en la codificación que aparenta.
• Nada de texto — Una imagen renombrada a .json se rechaza indicando eso como motivo, en vez de producir un error de sintaxis en la posición 0 para algo que nunca fue JSON.

Una sola pasada sobre los bytes, sin enviar nada a ninguna parte. Un documento de 22 MB se comprueba en unos 0,2 segundos en un portátil normal —incluidas claves duplicadas y precisión numérica— porque el analizador nunca construye los valores que comprueba.

• Válido — Un veredicto verde con el tipo raíz y el tamaño, y un informe de estructura: nodos totales, profundidad máxima, recuento de objetos, arrays y claves, el tamaño en líneas y bytes, y la codificación empleada.
• Inválido — Un veredicto rojo con todos los errores enumerados —línea, columna, JSON Pointer, una descripción clara y un cursor bajo el carácter exacto— además de un enlace al Formateador JSON.
• Avisos — Claves duplicadas, números que pierden precisión, escapes de sustitutos sin pareja y anidamiento inusualmente profundo, cada uno con su ubicación. No cambian el veredicto, porque un parser los aceptará.
• Un dialecto, cuando lo hay — Si el texto es JSON5, JSONC o un diccionario de Python válido, se dice con todas las letras, con la opción de convertirlo.

El JSON inválido rompe APIs, configuraciones y pipelines de datos, y normalmente los rompe lejos de donde está el error. Comprobarlo antes de enviar o guardar detecta erratas, comas ausentes, comas finales y caracteres sin escapar mientras aún tiene el archivo delante. Los avisos importan más: una clave duplicada o un identificador redondeado no producen error en ninguna parte, así que sobreviven a todas las pruebas y aparecen como datos que faltan semanas después. Todas las comprobaciones se ejecutan localmente, así que sus datos siguen siendo privados.

• Detectar errores pronto — Encuentre problemas de sintaxis antes de que rompan un despliegue o una integración, con la línea y la columna exactas en vez de una traza de un servidor.
• Detectar los silenciosos — Las claves duplicadas y la pérdida de precisión pasan todos los parsers y todos los validadores existentes. Son los fallos que llegan a producción.
• Comprobar la forma, no solo la sintaxis — Un JSON Schema convierte «analiza» en «es lo que el consumidor espera», antes de que el consumidor se entere.
• Privacidad — Nada se sube. Las respuestas de API privadas, los tokens de acceso y los esquemas internos se pueden comprobar sin salir de su dispositivo.

Todo lo que decide si un documento es válido es gratis. Todos los errores en vez del primero, las claves duplicadas, los avisos de precisión, JSON Schema, la detección de dialecto, la reparación, el modo NDJSON y el informe completo de estructura están disponibles en el plan gratuito. Pro añade escala, no funciones.

• Gratis — Un archivo cada vez, hasta 25 MB, además de pegar sin límite. Todas las comprobaciones, todos los avisos, validación con esquema y reparación incluidas.
• Pro — Hasta 100 archivos en una pasada, tamaños limitados por su dispositivo y no por nosotros, un ZIP de informes para todo el lote e informes JSON y CSV legibles por máquina para un paso de CI o un ticket.
• Por qué 25 MB — Es una medición, no un número redondo. Un documento de 22 MB se comprueba en unos 0,2 segundos, así que el límite queda donde un móvil de gama media sigue cómodo.

• Formateador JSON
• Minificar JSON
• Visor JSON
• Comparar JSON
• Ordenar claves JSON
• Eliminar claves JSON