Validar JSON en 2026: navegador vs VS Code vs jq

La semana pasada vi a un ingeniero senior pegar una carga JSON de 4 MB en VS Code y esperar doce segundos a que el linter terminara. Después buscó con Cmd+F el corchete que faltaba. Después se rindió, volvió a correr la llamada a la API y lo intentó de nuevo.

Todo ese rodeo era innecesario. Hay tres lugares donde vive la validación de JSON en 2026. El navegador, el editor y la terminal. Y cada uno gana en un escenario distinto. Confundirlos cuesta unos minutos al día. Una vez que dejas de confundirlos, dejas de notar la fricción por completo.

Esta es una guía de campo sobre qué herramienta gana de verdad para cada tarea.

Por qué "usa VS Code y ya" es un error

El validador de JSON integrado de VS Code es excelente. También es la peor respuesta para varias preguntas comunes, porque:

1. Carga el archivo entero en memoria. Un volcado de registros de 50 MB desde CloudWatch congela el renderizador por segundos antes de que puedas desplazarte.
2. Valida la sintaxis, no la forma. Sin una referencia $schema, obtienes una marca verde para cualquier blob estructuralmente válido. Ninguna ayuda con "¿es esta la respuesta que mi API devolvió ayer?"
3. Está acoplado a un espacio de trabajo. Pegar una carga improvisada en un búfer temporal significa elegir un nombre de archivo, elegir una carpeta e ignorar las advertencias de búfer sin guardar al salir.
4. No está en el servidor de producción. Cuando entras por SSH a una máquina a las 2 de la madrugada para inspeccionar lo que devolvió una API, el editor es irrelevante.

VS Code es el correcto cuando el JSON es parte de un proyecto. Archivos de configuración, fixtures, cargas validadas contra un esquema. Es el equivocado para casi todo lo demás.

Cuándo gana el navegador

La mayoría de la validación de JSON en la práctica es de una sola vez: "¿es válido este blob que acabo de pegar?" o "¿cómo se ve en realidad esta estructura anidada?"

Para eso, un formateador en el navegador es la respuesta más rápida. Ningún archivo que guardar, ningún búfer que cerrar, ningún esquema que conectar. Pegas, ves verde o rojo, y sigues.

Yo uso el formateador de JSON de TextKit para esto. La razón es aburrida e importante: imprime con formato, minifica y valida sin enviar la carga a ningún lado. Todo ocurre del lado del cliente. Eso importa cuando el JSON contiene el correo de un cliente o un token interno. Y casi siempre lo contiene, porque si no, no estarías hurgando en él.

El navegador gana específicamente cuando:

• La carga está entre 1 KB y 5 MB (por encima de eso, los navegadores también sufren).
• No necesitas consultar los datos, solo mirarlos.
• Quieres comparar dos cargas lado a lado. Formatea ambas, luego pégalas en la herramienta de comparación de texto de TextKit. Respeta el espacio en blanco y muestra la deriva estructural línea por línea. Esta es la forma más rápida de responder "¿qué cambió entre la respuesta de la API de ayer y la de hoy?"
• Estás en la máquina de otra persona y no confías en su versión de Node.

Una nota sobre la higiene del copiar y pegar. El JSON sacado de los registros del servidor suele venir con números de línea, marcas de tiempo o texto envolvente pegado. Limpiarlo a mano es irritante. Un buscar y reemplazar con regex puede quitar el prefijo en una pasada. El patrón ^\d{4}-\d{2}-\d{2}T[^\s]+\s+ cubre el prefijo de marca de tiempo ISO que rompe la mayoría de los analizadores.

Cuándo gana VS Code

VS Code es la herramienta correcta cuando el JSON es parte del proyecto, no un blob suelto.

La señal más clara: el archivo vive en tu repo y otra persona lo editará la semana que viene. Eso incluye:

• tsconfig.json, package.json, .eslintrc.json y el resto de la familia de configuración.
• Fixtures de solicitud y respuesta de API en un directorio de pruebas.
• Especificaciones OpenAPI y definiciones de JSON Schema donde IntelliSense importa.
• Cualquier archivo donde el historial de Git necesite rastrear los cambios.

En estos casos la validación contra el esquema del editor es lo esencial. Recurre al navegador y pierdes la navegación con Cmd-clic, el autocompletado, los errores de tipo contra el esquema y el atajo "Format Document" que tus manos ya conocen.

Un truco útil: si te pasan una carga JSON y sabes que está por convertirse en un fixture, pégala primero en un búfer temporal, guárdala como *.fixture.json y deja que VS Code empiece a insistir de inmediato. La fricción es el valor.

Cuándo gana jq

jq es la única respuesta correcta para tres cosas:

1. JSON de más de 10 MB. Sin navegador, sin editor, solo transmítelo en flujo.
2. JSON que necesitas consultar, no solo leer. "Dame el correo de cada usuario donde subscription.status == 'cancelled'" es una sola línea en jq y un ejercicio de diez minutos en cualquier interfaz.
3. JSON dentro de una tubería. Cuando la entrada es curl ... | jq y la salida alimenta a otro comando, ninguna herramienta gráfica encaja.

La curva de sintaxis de jq es real, pero el piso es bajo. Tres comandos cubren el 80% del uso práctico:

# Pretty-print and validate (exits non-zero on bad JSON)
cat response.json | jq .

# Pull a nested field out
cat response.json | jq '.data.users[0].email'

# Filter an array by predicate
cat response.json | jq '.data.users[] | select(.status == "cancelled") | .email'

Si eres nuevo en jq, el primer comando solo. jq .. Reemplaza el 90% de los flujos de "¿esto es válido?" una vez que lo interiorizas. El segundo y el tercero son los que lo hacen irreemplazable.

El costo de jq: está instalado-en-esta-máquina-o-no, y en Windows la experiencia es lo bastante áspera como para que la mayoría de los ingenieros ni se molesten. Por eso la herramienta del navegador se queda en la rotación incluso en configuraciones amigables con jq.

Un árbol de decisión que cabe en una ficha

Usa esto y acertarás el 95% de las veces:

• ¿El archivo está en el repo? → VS Code.
• ¿Carga de más de 10 MB, o necesitas consultar dentro de ella? → jq.
• ¿Un blob de una sola vez, solo quieres mirarlo o compartir una versión limpia? → formateador en el navegador.
• ¿Comparas dos cargas? → formatea ambas en el navegador, compáralas, y luego recurre a jq si necesitas profundizar.

La trampa es recurrir a VS Code por defecto porque ya está abierto. Es el más potente de los tres para el trabajo de proyecto y el más lento para la inspección puntual. La herramienta del navegador existe para la segunda categoría, y los pocos segundos que ahorra por inspección se acumulan en tiempo real a lo largo de una semana.

Una nota sobre los "validadores de JSON en línea"

Un número sorprendente de herramientas de JSON en línea envían tu carga a un servidor por POST. Para datos públicos pequeños está bien. Para cualquier cosa con información personal, IDs internos, claves de API, registros de clientes, o cualquier cosa que termine en un rastro de auditoría SOC 2. No lo está. La solución es usar una herramienta que corra por completo en el navegador y verificarlo abriendo la pestaña de red y vigilando las solicitudes salientes durante un ciclo de pegar y formatear. Si no ves ninguna, estás a salvo.

Esta es también la razón por la que los resultados de búsqueda de "JSON beautifier" de 2018 no son una gran respuesta en 2026. La mayoría de esos dominios se vendieron, la postura de privacidad cambió, y no hay forma fácil de auditar qué hacen con lo que pegas. Elige una herramienta cuya fuente de verdad puedas verificar, y luego deja de pensar en ello.

Pruébalo

La próxima vez que estés por pegar 200 líneas de JSON en el búfer temporal de tu editor, prueba mejor el formateador de JSON de TextKit. Si es un problema de diferencia estructural, el comparador de texto de TextKit toma la salida con formato y muestra exactamente qué claves se movieron.

Reserva VS Code para los archivos que de verdad viven en el repo. Para el flujo de limpieza más amplio en el que encaja la validación de JSON, mira Herramientas de texto para la era de la IA.