Resumen: JSON tiene una gramática pequeña y estricta — los errores que rompen un parser (comas finales, claves sin comillas, comillas simples) son invisibles en datos minificados pero obvios una vez formateados. Conocer las reglas de sintaxis reales convierte "la API devolvió un error" en una corrección de dos segundos. Combina esta guía con Encoding Converter, Character Counter, Text Difference y AI Hidden Characters.
Formatear JSON significa añadir espacios en blanco e indentación para hacer legible su estructura; validarlo significa comprobar que esa estructura realmente sigue la gramática definida en RFC 8259. El JSON minificado — la forma compacta sin espacios que las APIs realmente transmiten — es correcto pero ilegible; un formateador revierte eso sin cambiar los datos.
Las reglas de sintaxis que realmente importan
Las claves JSON deben ser cadenas entre comillas dobles — {name: "valor"} no es válido, solo {"name": "valor"} se analiza correctamente. Las comillas simples nunca son válidas para cadenas o claves, a diferencia de los literales de objeto de JavaScript, que la sintaxis de JSON restringe deliberadamente. Una coma final después del último elemento en un array u objeto — ["a", "b",] — es JSON inválido, aunque sea inofensiva (o incluso requerida por convención) en otros lenguajes, y es una de las razones más comunes por las que JSON editado a mano falla al analizarse.
Por qué "se ve bien" no es lo mismo que válido
Un documento JSON puede ser visualmente indistinguible de uno válido y aun así fallar al analizarse — una llave de cierre faltante al final de una gran estructura anidada, una comilla tipográfica (“) pegada desde un procesador de texto en lugar de una recta ", o un comentario perdido (JSON no tiene ninguna sintaxis de comentarios, a diferencia de JSON5 o JSONC) romperán todos un parser estricto mientras se ven bien a simple vista. Por eso formatear antes de mirar ayuda: una indentación correcta hace visualmente obvia una llave sin cerrar, rompiendo el patrón de anidamiento esperado.
Formateo vs. validación de esquema
Un formateador verifica que el JSON sea sintácticamente válido — llaves equilibradas, cadenas correctamente entre comillas, sin comas finales. No verifica si los datos tienen sentido: si un campo que debería ser un número es en realidad una cadena, o falta un campo requerido. Eso es una preocupación distinta, manejada por la validación de JSON Schema, que verifica estructura y tipos contra una definición de esquema en lugar de solo comprobar que el JSON en sí esté bien formado.
Un flujo de trabajo para JSON desordenado o roto
- Pega el JSON crudo — minificado, roto, o lo que sea — primero en un formateador.
- Si se analiza, revisa la estructura indentada para encontrar el campo o valor que realmente buscas.
- Si falla al analizarse, revisa primero la ubicación del error: la mayoría de los parsers reportan una línea/columna, que usualmente apunta directamente a una coma, llave o comilla faltante.
- Presta especial atención a comas finales y comillas tipográficas cuando la fuente fue escrita a mano o pegada desde un editor que no es de código.
Errores comunes que evitar
- Asumir que una indentación de aspecto válido significa JSON válido — formateo y análisis son pasos separados.
- Añadir una coma final por costumbre de JavaScript o Python, donde a menudo se tolera.
- Pegar JSON desde un procesador de texto y obtener comillas tipográficas curvas en lugar de rectas.
- Confundir "se formatea sin error" con "coincide con el esquema esperado por la API" — son comprobaciones distintas.
La mayoría de los errores JSON son un carácter específico en un lugar específico — el verdadero valor de un formateador es hacer visible ese lugar en lugar de dejarte escanear una sola línea ininterrumpida para encontrarlo.