Decodificador JWT
Inspecciona la cabecera, el payload y la caducidad de un JWT.
Acerca de esta herramienta
Decodifica un JSON Web Token para leer su cabecera y sus claims. Las marcas de tiempo como exp, iat y nbf se muestran como fechas legibles, y ves de un vistazo si el token ha caducado. La firma no se verifica.
Cómo se usa
- Pega un JSON Web Token. El prefijo “Bearer ” se elimina automáticamente.
- Consulta la cabecera y el payload decodificados.
- Mira el aviso de estado y los claims de tiempo para saber cuándo se emitió el token y cuándo caduca.
Preguntas
- ¿Verifica la firma?
- No. Solo decodifica el token. La verificación necesita el secreto o la clave pública y debe hacerse en tu servidor. No confíes nunca en un token solo porque se pueda decodificar.
- ¿Es seguro pegar aquí un token real?
- La decodificación se hace por completo en tu navegador y el token nunca se envía a ningún sitio. Aun así, trata los tokens de producción como contraseñas y, cuando puedas, usa tokens caducados o de prueba.
- ¿Qué significan exp, iat y nbf?
- exp es cuándo caduca el token, iat cuándo se emitió y nbf el momento antes del cual no debe aceptarse. Los tres son marcas de tiempo Unix en segundos.
- ¿Cualquiera puede leer el contenido de un JWT?
- Sí. La cabecera y el payload solo están codificados en Base64url, no cifrados. No pongas secretos ni datos personales sensibles en el payload de un JWT.
- ¿Por qué mi token tiene cinco partes en lugar de tres?
- Un token con cinco partes separadas por puntos es un JWE, un JSON Web Token cifrado definido en el RFC 7516. Su payload no se puede leer sin la clave de descifrado, así que este decodificador indica un error. Un token con solo dos partes normalmente se cortó al copiarlo; incluso un token sin firmar conserva un punto final.
- ¿Qué es el kid en la cabecera de un JWT?
- kid es el ID de la clave. Indica al verificador qué clave usar cuando el emisor publica varias, por ejemplo en un documento JWKS. Esto hace posible la rotación de claves: los tokens nuevos se firman con una clave nueva mientras que los firmados con la anterior siguen siendo válidos hasta que caducan.
- ¿Puedo editar el payload de un JWT y seguir usándolo?
- Puedes cambiar el payload y volver a codificarlo, pero la firma dejará de coincidir, así que un servidor bien configurado rechazará el token. Si se acepta un token editado, el servidor no está verificando las firmas, lo que es un fallo de seguridad grave que conviene notificar o corregir de inmediato.
¿Qué es un JWT y cómo es su estructura?
Un JSON Web Token, definido en el RFC 7519, es una cadena compacta de tres partes separadas por puntos: cabecera, payload y firma. La cabecera indica cómo se firma el token, con un valor alg como HS256 o RS256. El payload contiene los claims: a quién se refiere el token (sub), quién lo emitió (iss), a quién va destinado (aud) y cuándo caduca (exp). Ambas partes son JSON codificado en base64url.
La tercera parte es la firma, calculada sobre las dos primeras con un secreto o una clave privada. Como la cabecera es un JSON que empieza con una llave y unas comillas dobles, casi todos los JWT empiezan por eyJ, y así puedes reconocerlos en logs y cabeceras de solicitudes. Pega un token en este decodificador JWT para ver la cabecera y el payload formateados, con los claims de tiempo mostrados como fechas.
¿Por qué se rechaza mi JWT aunque se decodifica bien?
Un token que se decodifica sin problemas puede rechazarse igualmente, normalmente con un 401. La causa más común es la caducidad, así que mira el aviso de estado, que te indica si exp ya ha pasado. Recuerda que exp está en segundos: un backend que lo compare con una hora de JavaScript en milisegundos tomará la decisión equivocada. El desfase de reloj entre servidores también influye, por eso la mayoría de las bibliotecas permiten un pequeño margen.
Si las horas parecen correctas, compara los claims con lo que espera el servidor. Un aud que no coincide con la API, un iss inesperado o un token de un proveedor de identidad de staging enviado a producción no superan la validación. La comprobación de la firma falla cuando la clave es incorrecta, el token se ha editado o el alg de la cabecera no es uno que el servidor acepte. Este decodificador no verifica firmas, así que no puede decirte cuál de estos casos se aplica.
HS256 vs RS256: qué algoritmo de JWT usar
HS256 firma el token con HMAC-SHA256 y un único secreto compartido. Cada servicio que verifica tokens necesita ese mismo secreto, que además le permite crear tokens nuevos. Eso está bien para un único backend, pero es arriesgado cuando hay muchos servicios. RS256 (RSA) y ES256 (ECDSA) usan en cambio un par de claves: el emisor firma con una clave privada y todos los demás verifican con la clave pública, que a menudo se publica en un endpoint JWKS.
Elijas el que elijas, fija el algoritmo permitido en el lado que verifica en lugar de fiarte del campo alg de la cabecera. Un token con alg en none no lleva ninguna firma y siempre debe rechazarse. Mantén exp corto, de minutos y no de días, y usa refresh tokens para sesiones más largas. Aquí puedes leer alg y kid en el panel de la cabecera, y comprobar cualquier marca de tiempo con el Conversor de marcas de tiempo Unix.
¿Algo no funciona o un resultado parece incorrecto? Informar de un problema con esta herramienta