Formatear y Validar JSON
Formatea, valida y minifica JSON al instante.
Tus respuestas de API no salen de aquíFormatear, validar y minificar JSON online
Sobre este formateador de JSON
Pega cualquier JSON y obtén una versión limpia e indentada —con dos espacios, cuatro o tabulación— junto con la validación de sintaxis. Si el JSON es inválido, se muestra el mensaje de error exacto y la posición del carácter donde se detuvo el parser, para que lo corrijas rápido. También puedes minificarlo: elimina todos los espacios y saltos de línea opcionales para payloads compactos.
Todo ocurre localmente en tu navegador usando el parser nativo de JSON. Tus datos nunca salen de tu equipo, así que es seguro para respuestas de API, archivos de configuración y cualquier cosa con credenciales o datos de clientes.
La mayoría de los errores de "JSON inválido" vienen de esperar que el formato sea más grande de lo que es. El RFC 8259 define exactamente seis tipos de valor: cadena, número, objeto, arreglo, true/false y null. Las cadenas van solo entre comillas dobles, y como las claves son cadenas, también necesitan comillas dobles. Los números no pueden ser NaN, Infinity, hexadecimales, ni llevar un signo + delante o un cero a la izquierda. No hay comentarios ni comas finales. Tampoco existe un tipo fecha: las fechas viajan como cadenas ISO 8601 por convención, no por regla. Y en un punto el estándar es más flexible de lo que se cree: un documento JSON no tiene que ser un objeto ni un arreglo, así que 42, "hola" y null son cada uno un texto JSON válido y completo. Las especificaciones anteriores sí exigían objeto o arreglo arriba del todo; el RFC 8259 eliminó esa restricción.
Formatear implica parsear y volver a serializar, y ese viaje de ida y vuelta no siempre es sin pérdidas. Las claves duplicadas son el caso más traicionero: el RFC 8259 dice que los nombres deberían ser únicos y deja el resto sin definir, así que {"a":1,"a":2} regresa como {"a":2} sin ningún aviso. Los enteros mayores a 2^53−1 pierden precisión, porque los números de JavaScript son dobles IEEE 754: 12345678901234567890 se reformatea como 12345678901234567000. Un literal como 1e999 se desborda a Infinity al parsear y luego se serializa como null, y los ceros finales desaparecen (1.50 se vuelve 1.5). Además, las claves que parecen enteros no negativos se adelantan en orden numérico ascendente, así que {"10":…,"2":…,"nombre":…} sale como {"2":…,"10":…,"nombre":…}. Si algo de eso te importa —payloads firmados, IDs largos de bases de datos, cifras contables— usa un parser sin pérdidas: el módulo json de Python conserva enteros de precisión arbitraria, y en JavaScript necesitas una librería que use BigInt.
Esto es un formateador y validador, no un reparador: te dice dónde falló el parseo, no adivina lo que querías escribir. Acepta solo JSON estricto, así que un tsconfig.json con comentarios o un archivo .json5 se rechazan a propósito, y el NDJSON hay que pasarlo línea por línea. Todo corre de forma síncrona en la página, así que un archivo de cientos de megabytes va a congelar la pestaña; para eso, o para filtrar en vez de formatear, jq en la terminal es la herramienta correcta.
Errores de sintaxis en JSON: qué significa cada mensaje
Cuando JSON.parse falla, el navegador te dice qué regla se rompió y en qué carácter se rindió, con el formato "at position N (line L column C)". Un detalle que confunde a mucha gente: esos mensajes salen siempre en inglés aunque tengas Chrome en español, porque los genera el motor de JavaScript y no están traducidos. Chrome, Edge y Node usan el mismo motor (V8) y los redactan igual; Firefox y Safari los escriben distinto. En la tabla quitamos la posición porque depende de tu texto.
| Lo que escribiste | Lo que reporta Chrome | Cómo se arregla |
|---|---|---|
| {"a":1,} | Expected double-quoted property name in JSON | Borra la coma final. JSON no la permite nunca, ni en objetos ni en arreglos. |
| {'a':1} | Expected property name or '}' in JSON | Las comillas simples son de JavaScript, no de JSON. Usa comillas dobles. |
| {a:1} | Expected property name or '}' in JSON | Las claves son cadenas y van entre comillas: {"a":1}. |
| {"a":1 /* nota */} | Expected ',' or '}' after property value in JSON | Quita el comentario. Si necesitas comentarios, tu archivo es JSONC o JSON5, no JSON. |
| {"a":NaN} | Unexpected token 'N', … is not valid JSON | NaN e Infinity no son valores JSON. Usa null, o manda la cadena "NaN". |
| {"a":01} | Unexpected number in JSON | Quita el cero a la izquierda o ponlo entre comillas: "01". Códigos postales y números de cuenta van como texto. |
| {"a":"C:\x"} | Bad escaped character in JSON | La barra invertida se escapa: "C:\\x". Solo son válidos \" \\ \/ \b \f \n \r \t y \uXXXX. |
| Un salto de línea real dentro de una cadena | Bad control character in string literal in JSON | Escribe \n para el salto y \t para el tabulador. Los caracteres de control crudos no se permiten dentro de cadenas. |
La posición marca dónde se rindió el parser, no siempre dónde está tu error: la coma final de {"a":1,} se reporta en la posición 7 —la llave de cierre— porque el parser solo se da cuenta cuando busca la siguiente clave y encuentra } en su lugar. Lee hacia atrás desde ahí. Otros dos frecuentes: "Unexpected end of JSON input" significa que el texto se corta a media estructura, casi siempre una descarga truncada; y "Unexpected non-whitespace character after JSON" significa que hay un segundo documento pegado al primero, que es justo como se ve un archivo NDJSON de logs para un parser estricto.
Los acentos y la ñ son perfectamente válidos dentro de un JSON, siempre que el texto esté en UTF-8: {"ciudad":"Bogotá"} es correcto. También lo es {"ciudad":"Bogot\u00e1"}, y las dos formas decodifican al mismo carácter. Si tu JSON viene de PHP casi siempre verás la segunda: json_encode() escapa por defecto todo lo que no sea ASCII, y para que salga la tilde literal hay que pasar la bandera JSON_UNESCAPED_UNICODE. En cambio, si en lugar de tildes ves á o ñ, el problema no es el JSON sino la codificación del archivo: son los dos bytes UTF-8 de á (C3 A1) y de ñ (C3 B1) leídos como si fueran Windows-1252. Vuelve a guardar el archivo en UTF-8; no lo "arregles" con buscar y reemplazar, porque solo tapas el síntoma.
{
"cadena": "solo comillas dobles",
"numero": -1.5e3,
"objeto": { "anidado": true },
"arreglo": [1, 2, 3],
"booleano": false,
"nada": null
}Si tu archivo de verdad necesita comentarios, entonces no estás escribiendo JSON sino uno de sus primos, y esta herramienta los rechaza a propósito. JSONC (JSON con comentarios) es lo que usa VS Code para settings.json, tasks.json y launch.json: agrega comentarios // y /* */ y tolera comas finales, aunque el editor las marca con una advertencia. JSON5 va mucho más lejos: es un superconjunto que además permite claves sin comillas, cadenas con comillas simples y de varias líneas, números hexadecimales, punto decimal al inicio o al final, un + explícito, e Infinity y NaN. Ninguno de los dos pasa por JSON.parse, y ninguno debería enviarse a un endpoint que espera application/json. Quita los comentarios primero y luego formatea aquí arriba.
Preguntas frecuentes
¿Mi JSON se sube a un servidor?
No. El formateo y la validación corren completamente en tu navegador con JavaScript. No se envía nada a ningún lado.
¿Qué hace "minificar"?
Elimina todos los espacios y saltos de línea innecesarios, produciendo la versión válida más pequeña de tu JSON — útil para APIs y almacenamiento.
¿Por qué mi JSON es inválido?
Causas comunes: comas al final, comillas simples en vez de dobles, claves sin comillas o comentarios (el JSON estándar no permite ninguno de estos). El mensaje de error indica la posición exacta.