Introducción: El JSON Sin Formato Es Difícil de Leer, y el JSON Roto Es Difícil de Depurar
JSON (JavaScript Object Notation) es la forma más común en que las aplicaciones intercambian datos, pero el JSON que te encuentras en la práctica rara vez es agradable a la vista. Una API devuelve todo en una sola línea de 4.000 caracteres. Un archivo de configuración se ha editado a mano hasta que un error invisible rompe el parser entero. Una entrada de log contiene un objeto anidado de cinco niveles sin ningún salto de línea. En cada una de estas situaciones necesitas dos cosas rápidamente: una vista limpia e indentada que puedas leer de verdad, y una respuesta definitiva a la pregunta "¿es esto JSON válido y, si no, dónde está roto?"
Esta guía es un recorrido práctico y apto para principiantes sobre cómo formatear (también llamado embellecer o pretty-print), minificar y validar JSON directamente en tu navegador. Cubriremos cómo elegir un estilo de indentación limpia, qué comprueba realmente la validación, el puñado de errores que causan la inmensa mayoría de los fallos de JSON, y exactamente cómo corregir cada uno. Puedes seguir el ejemplo con nuestro formateador JSON, que hace todo esto localmente en tu navegador y nunca sube tus datos a ningún sitio.
Formatear vs. Minificar: Dos Caras de la Misma Moneda
Formatear y minificar son transformaciones opuestas de los mismos datos subyacentes. Ninguna cambia el significado del JSON — solo sus espacios en blanco.
Formatear (pretty-print) toma JSON compacto y añade saltos de línea e indentación para que la estructura se vuelva visible. Cada propiedad de un objeto va en su propia línea, los objetos y arrays anidados se indentan un nivel más profundo que su padre, y las llaves que se corresponden quedan alineadas verticalmente. Esto es lo que quieres cuando lees, revisas o depuras.
Un objeto minificado como este:
{"usuario":{"id":42,"nombre":"Ada","roles":["admin","editor"]}}
se convierte, tras formatearlo con indentación limpia, en:
{
"usuario": {
"id": 42,
"nombre": "Ada",
"roles": [
"admin",
"editor"
]
}
}
Minificar hace lo contrario: elimina cada espacio, tabulación y salto de línea no esencial, colapsando todo el documento en una sola línea. Esto es lo que quieres antes de enviar JSON por la red o incrustarlo en un archivo, porque un payload más pequeño se transfiere más rápido y consume menos ancho de banda. Las dos operaciones son sin pérdida y reversibles — puedes formatear JSON minificado para leerlo, y luego volver a minificarlo para enviarlo, y los datos son idénticos byte a byte en su significado.
Elegir un Estilo de Indentación: 2 Espacios, 4 Espacios o Tabulaciones
Cuando formateas JSON, eliges cuánto se indenta cada nivel de anidamiento. No hay una única respuesta correcta, pero sí hay opciones por defecto sensatas y compromisos que conviene entender.
- 2 espacios es la opción por defecto más popular en el ecosistema de JavaScript y la web. Evita que las estructuras muy anidadas se desplacen demasiado hacia la derecha, así que más parte de cada línea permanece visible sin desplazamiento horizontal. Herramientas como Prettier y el ecosistema de npm usan 2 espacios por defecto, y por eso la mayor parte del JSON que ves online los utiliza.
- 4 espacios produce más separación visual entre niveles de anidamiento, lo que a algunas personas les resulta más fácil de escanear, especialmente en documentos poco profundos. Es común en bases de código influidas por Python. La desventaja es que el JSON muy anidado se queda rápidamente sin espacio horizontal.
- Tabulaciones usan un único carácter de tabulación por nivel en lugar de espacios. La ventaja es que cada lector puede configurar cómo de ancha se ve una tabulación en su propio editor, de modo que una persona puede verla como 2 columnas y otra como 8. La desventaja es que las tabulaciones se renderizan de forma inconsistente en páginas web, visores de diferencias y terminales, y mezclar tabulaciones con espacios produce una salida desordenada y mal alineada.
La regla práctica: elige un estilo por proyecto y mantenlo. Si estás formateando JSON que se va a subir a un repositorio, iguala el estilo que ya use el resto del proyecto para que tu cambio no genere un diff ruidoso en el que cada línea parezca modificada. Si es JSON desechable que solo estás inspeccionando, 2 espacios es una opción por defecto segura y compacta. Un buen formateador online te deja alternar entre 2 espacios, 4 espacios y tabulaciones y volver a renderizar al instante, así que puedes probar varias y ver cuál se lee mejor para tus datos concretos.
Qué Detecta Realmente la Validación
La validación responde a una pregunta estricta de sí o no: ¿este texto se ajusta a la gramática JSON definida en el RFC 8259? Un validador analiza el documento carácter a carácter y se detiene en la primera cosa que viola la gramática, informando de la línea y columna donde se rindió. Es importante entender qué comprueba y qué no.
La validación sí confirma que: las cadenas están correctamente entre comillas dobles y sus secuencias de escape son legales; las llaves y los corchetes están balanceados y correctamente anidados; las comas separan elementos pero no quedan sueltas tras el último; las claves son cadenas; y los números, true, false y null están escritos en su forma canónica. Si el parser llega al final de la entrada con un valor completo y bien formado, el documento es JSON válido.
La validación no comprueba que tus datos signifiquen lo correcto. Un documento JSON sintácticamente perfecto puede tener aún nombres de campo equivocados, propiedades obligatorias ausentes, una cadena donde esperabas un número, o una dirección de email que no es realmente un email. Esa comprobación más profunda, a nivel de significado, es trabajo de un esquema, que es un paso aparte. Si necesitas forzar estructura y tipos, nuestro formateador JSON combina de forma natural con la validación por esquema para detectar ambos tipos de problemas. Para un tratamiento más amplio del diseño de payloads bien estructurados, consulta nuestra guía de buenas prácticas de JSON para el desarrollo de APIs.
Los Errores de JSON Más Comunes y Cómo Corregir Cada Uno
Casi todos los fallos al parsear JSON provienen de un pequeño conjunto de errores. Aprender a reconocerlos convierte un críptico mensaje "Unexpected token" en una corrección de cinco segundos.
1. Comas Finales (Trailing Commas)
Este es el error de JSON más frecuente. En el código fuente de JavaScript se te permite dejar una coma tras el último elemento de un array o un objeto, pero JSON lo prohíbe. El RFC 8259 exige que las comas solo separen dos elementos — no puede haber nada más que espacios en blanco entre el último elemento y su corchete o llave de cierre.
Roto: {"a": 1, "b": 2,} — la coma tras el 2 es ilegal.
Corregido: {"a": 1, "b": 2}
La corrección es siempre borrar la coma que está justo antes de una } o ] de cierre. Un validador te apunta directamente a ella, normalmente informando del error en el corchete de cierre que sigue a la coma sobrante.
2. Comillas Simples en Lugar de Comillas Dobles
Las cadenas de JSON — tanto las claves como los valores de texto — deben ir entre comillas dobles. Las comillas simples son válidas en JavaScript y Python, pero no son JSON. Esto suele tropezar a quien copia un objeto literal de su código y espera que sea JSON válido.
Roto: {'nombre': 'Ada'}
Corregido: {"nombre": "Ada"}
La corrección es reemplazar cada comilla simple alrededor de una clave o cadena por una comilla doble. Ten cuidado con los apóstrofos dentro de un valor: un nombre como O'Brien es perfectamente válido dentro de comillas dobles ("O'Brien") y no hay que tocarlo.
3. Claves Sin Comillas
En JavaScript puedes escribir un objeto como {nombre: "Ada"} con una clave desnuda y sin comillas. JSON no lo permite; cada clave debe ser una cadena entre comillas dobles.
Roto: {nombre: "Ada", edad: 30}
Corregido: {"nombre": "Ada", "edad": 30}
La corrección es envolver cada clave entre comillas dobles. Este error y el de las comillas simples suelen aparecer juntos cuando alguien pega un objeto literal de JavaScript y da por hecho que es JSON — los dos lenguajes se parecen, pero JSON es un subconjunto estricto y entrecomillado.
4. Llaves o Corchetes Ausentes o Mal Emparejados
Cada { de apertura necesita una } de cierre, y cada [ de apertura necesita un ] de cierre, correctamente anidados. Una llave ausente, una de más, o cruzarlas (cerrar un array con una llave) rompe el documento. Estos errores son comunes tras editar manualmente un archivo grande, porque es fácil borrar por accidente uno de los dos elementos de un par.
Roto: {"items": [1, 2, 3} — el array se cierra con una llave.
Corregido: {"items": [1, 2, 3]}
La forma más fiable de encontrar una llave sin pareja es formatear el documento. Una vez indentado, los corchetes mal emparejados se vuelven visualmente obvios porque los niveles de indentación dejan de alinearse. Un validador suele informar del error en el punto donde esperaba un cierre pero encontró otra cosa, lo que te sitúa en la zona del fallo.
5. Problemas de BOM y Codificación
A veces el JSON parece completamente correcto y aun así falla al parsear, y el culpable es invisible. Una causa habitual es la marca de orden de bytes (BOM) — una secuencia especial e imprimible que algunos editores (en particular versiones antiguas del Bloc de notas de Windows) insertan al principio de un archivo al guardarlo como UTF-8. El RFC 8259 establece que el texto JSON debe codificarse en UTF-8 y que las implementaciones no están obligadas a aceptar un BOM inicial, de modo que un BOM al comienzo del archivo puede provocar un error de parseo en el primer carácter aunque el texto visible sea impecable.
Otros problemas invisibles incluyen espacios de no separación (non-breaking spaces) pegados desde una página web o un procesador de textos (que parecen espacios normales pero son un carácter distinto), comillas tipográficas o "inteligentes" que un procesador de textos sustituyó por comillas rectas, y caracteres de control sueltos. La corrección es volver a guardar el archivo como UTF-8 sin BOM, reescribir cualquier comilla sospechosa como comillas dobles rectas, y reemplazar los espacios exóticos por espacios normales. Si un documento valida cuando lo reescribes a mano pero falla cuando lo pegas, un carácter invisible es casi siempre la razón.
6. Comentarios, Números Especiales y Otros Añadidos que No Son JSON
Algunas costumbres más de otros lenguajes producen JSON inválido. Los comentarios no están permitidos — ni // comentarios de línea ni /* comentarios de bloque */ — así que elimínalos o muévelos a un campo de cadena real. Los valores especiales de coma flotante NaN, Infinity y -Infinity no son números JSON válidos; debes representarlos como cadenas o como null e interpretarlos en tu aplicación. Y aunque JSON permite técnicamente claves duplicadas dentro de un objeto, la mayoría de los parsers conservan silenciosamente solo la última, así que los duplicados es mejor tratarlos como un fallo a corregir que como una característica en la que confiar.
Minificar JSON: Cuándo y Por Qué
Una vez que tu JSON es válido, minificarlo es el paso final natural antes de enviarlo o almacenarlo. La minificación elimina la indentación y los saltos de línea que lo hacían legible, encogiendo el payload. Para un objeto de configuración grande o una respuesta de API, esto puede reducir de forma apreciable el tamaño de transferencia. El flujo de trabajo es simple: formatea mientras trabajas para poder leer y verificar la estructura, y luego minifica la versión final para su entrega. Como la transformación solo toca los espacios en blanco, un valor que era válido al formatearlo sigue siendo válido — e idéntico en significado — al minificarlo.
Una nota práctica: la minificación y la compresión del lado del servidor (gzip o brotli) se solapan. Si tu servidor ya comprime las respuestas, el ahorro adicional de la minificación es menor, pero minificar sigue ayudando a los clientes que no solicitan compresión y reduce ligeramente el coste de parseo en memoria. Formatear para las personas y minificar para las máquinas es, en cualquier caso, una buena costumbre por defecto.
Por Qué una Herramienta del Lado del Cliente Mantiene tus Datos Privados
El JSON contiene a menudo información sensible: claves de API, tokens de autenticación, registros de clientes, identificadores internos o datos personales en un payload de respuesta. Pegar eso en un sitio web que lo envía a un servidor para procesarlo significa entregar tus datos a un tercero del que puede que no sepas nada. Eso es un riesgo real de privacidad y seguridad, especialmente con credenciales de producción o datos regulados.
Una herramienta del lado del cliente evita el problema por completo. Nuestro formateador y validador JSON se ejecuta completamente en tu navegador usando JavaScript. Cuando pegas JSON y pulsas formatear, el parseo, la indentación y la validación ocurren todos en tu propia máquina. No se sube nada, no se registra nada en un servidor, y la herramienta funciona incluso si te desconectas de internet después de cargar la página. Obtienes la comodidad de una herramienta online con la privacidad de una offline — que es exactamente lo que quieres cuando los datos que inspeccionas no son tuyos para filtrarlos.
Un Flujo Sencillo para Formatear y Validar JSON Online
- Pega tu JSON en el área de entrada del formateador. Puede ser una única línea minificada, un bloque parcialmente formateado, o algo que acabas de editar a mano.
- Formatéalo para embellecerlo con tu indentación limpia elegida. Si la estructura se renderiza limpia y con los corchetes alineados, ya puedes ver la forma de tus datos.
- Lee el resultado de la validación. Si el JSON es válido, obtienes una confirmación. Si no, la herramienta informa de la línea y columna del primer error — ve allí y aplica la corrección correspondiente de la lista anterior.
- Corrige y vuelve a comprobar hasta que valide. La mayoría de los documentos solo tienen uno o dos de los errores comunes, y cada corrección es mecánica una vez que ves dónde está.
- Minifica la versión final si estás a punto de enviarla o almacenarla, y copia la salida compacta.
Con este bucle, formatear y validar JSON se convierte en una tarea rutinaria y sin estrés en lugar de una caza de un error invisible. Aprende los seis errores comunes, mantén un estilo de indentación consistente, y usa una herramienta basada en el navegador que mantiene tus datos en tu propia máquina. Cuando quieras profundizar en cómo se definen realmente los objetos JSON, nuestra explicación sobre la sintaxis de objetos del RFC 8259 cubre la gramática en detalle, y nuestra guía de buenas prácticas de JSON muestra cómo diseñar payloads fáciles de formatear, validar y consumir.