Decodificador JWT
Pega un JSON Web Token para leer su header y su payload, ver cuándo caduca y entender cada claim. Tu token nunca sale de tu navegador.
Funciona en tu navegadorSin registroNo se sube nada
Decodificar no es verificar. Cualquiera puede leer el header y el payload de un JWT, porque solo están codificados en base64url. Esta herramienta muestra lo que el token afirma; no demuestra que sea auténtico. Verifica siempre la firma en tu servidor.
Header
Payload
Claims explicados
Verificar firma (opcional, HS256/HS384/HS512)
Comprueba una firma HMAC con el secreto que introduzcas, usando la Web Crypto API de tu navegador. El secreto nunca sale de esta página. Los tokens RSA/ECDSA necesitan la clave pública del emisor y no se verifican aquí.
Cómo usar: Decodificador JWT
- Pega el token en el cuadro Token codificado. Se ignora el prefijo
Bearerde una cabecera Authorization. - El header y el payload se decodifican al instante y se muestran como JSON formateado.
- Lee la tabla Claims explicados:
exp,iatynbfse convierten en fechas con tiempos del tipo «caduca en» / «caducó hace». - Revisa la barra de estado para ver problemas de caducidad y las advertencias sobre configuraciones arriesgadas como
alg: none. - Si quieres, introduce el secreto compartido para verificar localmente una firma HS256, HS384 o HS512.
¿Qué hay dentro de un JWT?
Un JSON Web Token (RFC 7519) son tres cadenas base64url unidas por puntos: header.payload.signature. El header indica el algoritmo de firma (alg) y el tipo de token. El payload contiene los claims, como quién es el usuario y cuándo caduca el token. La firma se calcula sobre las dos primeras partes con un secreto o una clave privada.
Decodificar no es verificar
El header y el payload solo están codificados, no cifrados, así que cualquiera que tenga el token puede leerlos. Por eso nunca debes poner contraseñas ni secretos en el payload de un JWT. Decodificar te dice lo que un token afirma. Verificar la firma, normalmente en tu servidor de API con una librería como jose o PyJWT, demuestra quién lo emitió y que no se ha modificado. Un servidor también debe comprobar exp, nbf, iss y aud, y rechazar algoritmos inesperados.
Chuleta de claims registrados
| Claim | Significado |
|---|---|
iss | Emisor: quién creó y firmó el token |
sub | Sujeto: normalmente el ID del usuario |
aud | Audiencia: a qué API va destinado el token |
exp | Fecha de caducidad, en segundos desde la época Unix |
nbf | No es válido antes de este momento |
iat | Momento de emisión |
jti | ID único del token, útil para listas de revocación |
Depurar errores de «token expired»
Si una API rechaza un token que parece reciente, compara exp y nbf con el reloj del servidor. Es habitual un pequeño desfase de reloj entre máquinas, por eso la mayoría de librerías permiten un margen de 30-60 segundos. Comprueba también que exp esté en segundos: un valor en milisegundos es un error frecuente y sitúa la caducidad miles de años en el futuro.
Preguntas frecuentes
¿Es seguro pegar aquí un JWT de producción?
¿Esta herramienta verifica la firma del JWT?
¿Por qué mi token aparece como caducado?
exp está en el pasado respecto al reloj de tu equipo. Solicita un token nuevo o renuévalo con tu refresh token. Si las horas parecen incorrectas, comprueba si hay desfase de reloj o un valor exp escrito en milisegundos.¿Qué diferencia hay entre JWT, JWS y JWE?
¿Por qué es peligroso alg «none»?
alg: none y aceptar solo el algoritmo concreto que esperan.