Inspecciona cualquier token JWT
Los JSON Web Tokens (JWT) son omnipresentes en la autenticación web moderna: los usan APIs, aplicaciones móviles y sistemas de inicio de sesión. Cuando depuras un problema de autenticación, a menudo necesitas ver qué hay dentro del token: qué algoritmo usa, qué datos contiene y cuándo caduca. Esta herramienta decodifica esas partes al instante, sin enviar el token a ningún servidor.
Las tres partes de un JWT
- Cabecera: indica el tipo de token y el algoritmo de firma (por ejemplo, HS256).
- Contenido (payload): los datos o «claims», como el usuario, los permisos o las fechas de validez.
- Firma: garantiza que el token no se ha modificado. Se verifica en el servidor con una clave secreta.
Las tres piezas van pegadas y separadas por un punto, siempre en ese orden. Las dos primeras son JSON convertido a Base64URL, una variante del Base64 de toda la vida que cambia los dos símbolos que dan problemas dentro de una dirección web y suele prescindir del relleno final. Gracias a eso un token cabe en una cabecera HTTP o en un parámetro sin romper nada.
Los claims que casi siempre vas a ver
Cada dato del payload se llama claim y el estándar reserva unos cuantos nombres cortos con un significado fijo:
- sub — el sujeto: quién es el titular del token, normalmente el identificador del usuario.
- iss — el emisor: qué sistema lo generó.
- aud — la audiencia: para qué servicio está destinado. Un token emitido para una API no debería aceptarse en otra.
- iat — el momento en que se emitió.
- exp — el momento en que deja de valer.
- nbf — a partir de cuándo empieza a ser válido, útil para tokens programados.
- jti — un identificador único, pensado para poder invalidar un token concreto.
Las tres fechas viajan como marcas de tiempo Unix, es decir, segundos contados desde 1970, así que a simple vista no dicen nada; la herramienta las traduce a fecha y hora legibles. Junto a estos claims registrados suele haber otros propios de cada aplicación, como el rol, los permisos o el correo.
HS256 y RS256: quién puede firmar y quién puede comprobar
El campo alg de la cabecera anuncia el algoritmo. Con HS256 existe una única clave secreta que sirve tanto para firmar como para verificar, algo práctico cuando el emisor y el validador son el mismo sistema, pero que obliga a compartir ese secreto con todo el que necesite comprobar tokens. Con RS256 hay dos claves: el emisor firma con la privada y cualquiera puede verificar con la pública, que es el modelo de los proveedores de identidad externos. Ver el algoritmo antes de depurar ahorra tiempo, porque un desajuste entre lo que firma y lo que valida es una causa frecuente de rechazos.
Codificado no es cifrado
Es un malentendido muy común: el contenido de un JWT no está cifrado, solo codificado en Base64URL. Eso significa que cualquiera que tenga el token puede leer su payload (esta herramienta lo demuestra). La firma no oculta los datos, solo certifica que no han sido alterados. La consecuencia práctica es clara: nunca guardes contraseñas ni datos sensibles dentro de un JWT.
Decodificar no es verificar
Conviene separar bien las dos operaciones. Decodificar es deshacer el Base64URL y leer el contenido: no necesita ninguna clave y por eso puede hacerse aquí mismo, en tu navegador. Verificar es recalcular la firma con la clave correspondiente y comprobar que coincide, además de revisar la caducidad y la audiencia. Eso solo puede hacerlo el servidor que custodia la clave. Un token bien formado y legible puede estar perfectamente falsificado; leerlo sirve para diagnosticar, jamás para conceder acceso.
Cuando el problema es la caducidad
Buena parte de los fallos de autenticación se explican mirando dos números. Si la fecha de exp ya ha pasado, el servidor rechazará el token por mucho que la firma sea correcta: toca renovarlo con el mecanismo de refresco que use tu sistema. Si en cambio el token parece recién emitido y aun así falla, revisa la fecha de iat y el reloj de la máquina, porque un desfase de unos minutos entre servidores basta para que un token se considere emitido en el futuro y se descarte.
Dónde pegas un token no da igual
Un token de acceso es una credencial en toda regla: quien lo tiene puede actuar en tu nombre hasta que caduque. Pegarlo en un servicio que lo envía a su servidor para decodificarlo equivale a entregarle las llaves a un desconocido, aunque prometa no guardarlas. Este decodificador funciona enteramente dentro de tu navegador: el token no se transmite ni se almacena, y al cerrar la pestaña desaparece. Aun así, la buena costumbre cuando trabajas con producción es usar tokens de prueba o revocar el que hayas manipulado.
Herramientas relacionadas
Como el JWT se apoya en Base64, te pueden interesar el codificador Base64, el formateador de JSON y el generador de hash. Para traducir los claims de fecha a mano tienes el conversor de timestamp. Más en herramientas de archivos.