Cómo se usa
- Pegue el token en JWT. Tiene tres partes separadas por puntos.
- Lea Algoritmo de firma para ver cómo indica el token que está firmado.
- Compruebe la Caducidad. En verde, el token sigue siendo válido según la hora de su dispositivo.
- Lea Claims y Carga útil para ver para quién es el token y qué contiene.
Qué contiene un JWT
Un token web JSON tiene tres partes separadas por puntos. Las dos primeras son objetos JSON codificados en base64url: la cabecera indica cómo se firma el token, y la carga útil contiene los claims, que son afirmaciones como para quién es el token o cuándo caduca. La tercera parte es la firma.
La RFC 7519 define siete nombres de claim registrados: iss, sub, aud, exp, nbf, iat y jti. La tabla explica cada uno, y los tres claims de tiempo también se muestran como fechas en su idioma.
Decodificar no es verificar
Esta página solo decodifica el token. No comprueba la firma, porque eso necesita la clave con la que se firmó, y una clave de verificación es secreta. Un token decodificado puede seguir siendo falsificado, así que no confíe en un claim solo porque pueda leerlo aquí.
Para verificar un token, su servidor o su biblioteca debe comprobar la firma con la clave correcta y el algoritmo esperado, y debe rechazar un token cuya firma no coincide.
Cómo se lee la caducidad
El claim exp es un número de segundos desde el 1 de enero de 1970 a las 00:00 UTC. La RFC 7519, sección 4.1.4, dice que un token no debe aceptarse en ese momento ni después, así que en la hora exacta ya cuenta como caducado.
Un token sin claim exp nunca caduca. La página lo muestra en rojo, porque un token que nunca caduca es un riesgo que conviene conocer.
Ejemplo resuelto: el token de ejemplo de la RFC 7519
El ejemplo de la RFC 7519, sección 3.1, tiene la cabecera alg HS256, y la carga útil iss joe, exp 1300819380 y un claim propio. El valor de exp es el 22 de marzo de 2011 a las 18:43 UTC, así que la página muestra el token como caducado. La firma no se comprueba, así que el resultado es el mismo para cualquier firma.
| Claim | Valor | Significado |
|---|---|---|
| iss | joe | Emisor: quién creó el token |
| exp | 1300819380 (22 de marzo de 2011 a las 18:43 UTC) | Hora de caducidad |
| http://example.com/is_root | true | Un claim propio |
Preguntas frecuentes
¿Se envía mi token a algún servidor?
No. El token se decodifica en su navegador, y la página no lo guarda ni lo envía. Puede comprobarlo decodificando un token con la conexión a internet desactivada, después de cargar la página.
¿Esta página comprueba que el token es auténtico?
No. Lee solo la cabecera y los claims. Comprobar la firma necesita la clave con la que se firmó el token, que esta página nunca pide. Su aplicación debe hacer esa comprobación.
¿Por qué la página dice que un token ha caducado si mi aplicación todavía lo acepta?
Su aplicación puede permitir un periodo de gracia, o comprobar la caducidad con su propio reloj. La página compara exp con la hora de su dispositivo, así que un reloj mal ajustado también puede cambiar el resultado.
¿Qué significa el algoritmo none?
La cabecera indica que el token no tiene firma. Cualquiera puede escribir un token así, así que un servicio no debe aceptarlo para nada importante. La página lo marca con una nota.
¿Por qué una fecha muestra una hora que no esperaba?
La fecha se muestra en su idioma y en su zona horaria, con el nombre de la zona al final. El número anterior es el valor guardado en el token: segundos desde 1970 en UTC.
¿Puede esta página leer un token cifrado?
No. Un token cifrado tiene cinco partes, y su contenido no se puede leer sin la clave. Esta página lee solo los tokens firmados, que tienen tres partes.
Fuentes
- RFC 7519 (en inglés): JSON Web Token (JWT)
- RFC 7518 (en inglés): JSON Web Algorithms, los valores alg en la sección 3.1
- RFC 4648 (en inglés): codificación base64url en la sección 5
Cifras y texto revisados por última vez el martes, 10 de noviembre de 2026.