Los JWT están en todas partes. Cada vez que inicias sesión en una aplicación web, una API te emite un JSON Web Token, y ese token lleva tu identidad, tus permisos y a menudo algunos detalles personales en su carga útil. El formato en sí fue estable durante una década, luego hubo una flurry de actividad en 2024-2025 — RFC 8725 (mejores prácticas actuales de JWT) se convirtió en un requisito obligatorio para nuevas especificaciones, el debate de “los JWT son malos” se reavivó sobre el tamaño de las sesiones, y varios proveedores grandes migraron a tokens opacos para uso en el navegador. El resultado: más desarrolladores que nunca están inspeccionando tokens manualmente. Cuando algo sale mal — tu sesión expira en el momento equivocado, una API rechaza un token que pensabas que era válido, un colega dice “¿qué hay en el JWT?” — lo primero que hace la mayoría de los desarrolladores es pegar el token en un decodificador en línea.
El problema: la mayoría de esos decodificadores envían tu token a un servidor. El token en sí no es un secreto (es solo JSON codificado en base64), pero el contenido de la carga útil a menudo lo es: un ID de usuario, un correo electrónico, a veces un ID de sesión, a veces una lista de permisos. Si tu servicio usa JWT para comunicarse con otros servicios internos, la carga útil podría incluso incluir nombres de servicios internos o indicadores de funciones.
Un token pegado en un decodificador de terceros es una pequeña fuga de información. La mayoría de las veces no importa. Pero el principio importa: deberías poder inspeccionar un token sin confiar en la infraestructura de otra persona.
Cómo se ve realmente un JWT
Un JWT son tres cadenas codificadas en base64url, separadas por puntos:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cLas tres partes son la cabecera, la carga útil y la firma. Decodifica las dos primeras y obtienes JSON:
// Header
{
"alg": "HS256",
"typ": "JWT"
}// Payload
{
"sub": "12345",
"name": "Alice",
"iat": 1516239022
}La firma es un hash criptográfico que demuestra que el token fue emitido por alguien que conoce el secreto. Cualquiera puede decodificar la carga útil — ese no es el límite de seguridad. El límite de seguridad es si puedes verificar la firma.
La distinción entre verificación y decodificación
Aquí es donde muchos desarrolladores se equivocan. Decodificar no es verificar. Un decodificador solo decodifica el JSON en base64 para que puedas leerlo. Cualquiera puede hacer eso, y no demuestra que el token sea auténtico. La verificación es el acto de comprobar la firma contra un secreto conocido para confirmar que el token no fue alterado.
- Para depurar el contenido de un token (qué reclamaciones tiene, cuándo expira), la decodificación es suficiente.
- Para autenticar a un usuario, necesitas verificación, y tiene que ocurrir en un servidor en el que confíes.
La mayoría de las herramientas de decodificación en línea solo decodifican. Muestran la cabecera y la carga útil pero nunca piden tu secreto — porque no están verificando, simplemente te muestran lo que hay en el token.
Cómo decodificar localmente
No necesitas una herramienta de terceros para esto. Un JWT son solo tres cadenas base64url. Abre una terminal:
echo 'eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTUxNjIzOTAyMn0' | tr '_-' '/+' | base64 -dEsa es la carga útil. La cabecera es el primer segmento, el mismo truco.
Si prefieres no memorizar el baile de tr '_-' '/+', el decodificador JWT de DevSpeedTools hace lo mismo en el navegador. Sin solicitud de red, sin subida, sin registro. Abre DevTools → Network, pega un token y confirma por ti mismo que nada sale de tu máquina.
Cuándo realmente necesitas verificación
Si estás tratando de depurar un problema de autenticación y necesitas saber si el token es válido (no solo qué contiene), necesitas verificar la firma. La verificación tiene que ocurrir con el mismo secreto o clave pública que usa tu servidor de autenticación. Eso significa que tiene que ocurrir en infraestructura que controles.
Algunas opciones de verificación que no implican pegar tu secreto en un sitio web:
- En Node.js:
jsonwebtoken.verify(token, process.env.JWT_SECRET). - En Python:
jwt.decode(token, key, algorithms=['HS256']). - En Go:
token, err := jwt.Parse(tokenString, keyFunc). - CLI:
jwt-cli(Rust) opyjwtcon una línea de comandos.
Si de alguna manera necesitas un verificador en línea, busca uno que diga explícitamente que se ejecuta en el navegador (la fuente generalmente es visible). Las herramientas honestas lo dicen. El resto debes asumir que suben tu token a un servidor.
El error “invalid signature”
Una razón común por la que los desarrolladores terminan en un decodificador es el error invalid signature. Ese mensaje hace dos cosas:
- Te dice que el token fue firmado con un secreto diferente al que estás usando para verificar.
- Te dice que el token puede haber sido alterado.
O — y esto es lo que la mayoría de la gente pasa por alto — el token puede haber expirado. Revisa la reclamación exp en la carga útil. Si la marca de tiempo Unix actual pasó exp, el token no es válido. Algunas bibliotecas lanzan invalid signature para tokens expirados, lo cual es engañoso.
El decodificador JWT muestra el valor de exp junto con el resto de la carga útil para que puedas detectar tokens expirados de un vistazo. Lo mismo aplica para nbf (no antes), iat (emitido en) y aud (audiencia) — todo útil para depuración.
El resumen
Los decodificadores JWT son útiles. También son un lugar donde los desarrolladores se vuelven descuidados al pegar tokens de producción. Un predeterminado más seguro:
- Usa un decodificador local o en el navegador para inspección rápida. Sin subida, sin fuga.
- Usa una CLI o tu propio código para verificación. Nunca pegues un secreto en un sitio web.
- Primero revisa las reclamaciones estándar —
expexpirado es la causa de la mayoría de los problemas de “mi token dejó de funcionar de repente”.
El token no es un secreto. El contenido del token a menudo lo es. Trátalo en consecuencia.