Cómo se usa
- Pega el token completo: tres partes Base64URL separadas por puntos.
- Lee el encabezado y la carga útil decodificados. Los claims exp, iat y nbf se muestran como fechas, con un aviso si el token ha caducado o aún no es válido.
- Para verificar la firma, introduce la clave secreta compartida si el algoritmo es HS256, HS384 o HS512, o pega la clave pública PEM si es un algoritmo RS, PS o ES.
- Comprueba que los claims de emisor, audiencia y sujeto coinciden con lo que espera tu aplicación.
Cómo se construye un JWT
Un JSON Web Token (RFC 7519) tiene tres partes separadas por puntos: header.payload.signature. El encabezado y la carga útil son objetos JSON codificados en Base64URL sin relleno; por eso los tokens casi siempre empiezan por eyJ, la forma codificada de un {" de apertura. La firma se calcula sobre las dos primeras partes exactamente tal como aparecen en el token.
- Encabezado: el algoritmo de firma en
alg, normalmente"typ": "JWT"y a menudo unkidque identifica la clave. - Carga útil: los claims, como quién es el usuario, quién emitió el token y cuándo caduca.
- Firma: una firma HMAC, RSA o ECDSA que demuestra que el encabezado y la carga útil no se han modificado.
Un token con cinco partes es un JWE cifrado; su contenido no se puede leer sin la clave de descifrado.
Claims registrados
| Claim | Nombre | Significado |
|---|---|---|
iss | Emisor (issuer) | Quién creó y firmó el token |
sub | Sujeto (subject) | A quién se refiere el token, normalmente un ID de usuario |
aud | Audiencia (audience) | El servicio al que va destinado el token |
exp | Caducidad (expiration time) | A partir de este momento el token debe rechazarse |
nbf | No antes de (not before) | Antes de este momento el token debe rechazarse |
iat | Emitido (issued at) | Cuándo se creó el token |
jti | ID de JWT (JWT ID) | Identificador único, usado para detectar ataques de repetición |
Las horas son valores NumericDate: segundos desde el 1 de enero de 1970 UTC, no milisegundos. El decodificador las muestra como fechas legibles y las compara con el reloj de tu dispositivo.
Decodificar no es verificar
Cualquiera puede decodificar un JWT, porque la carga útil solo está codificada, no cifrada; nunca incluyas en ella contraseñas ni otros secretos. La confianza solo se obtiene comprobando la firma con la clave correcta, y un servidor que acepta tokens también debe:
- permitir únicamente el algoritmo que espera y rechazar
"alg": "none", que indica un token sin firmar; - no dejar nunca que el encabezado del token elija entre HMAC y RSA, porque un atacante podría firmar un token falsificado usando tu clave pública como secreto HMAC;
- comprobar
exp,nbf,issyauden cada petición.
La verificación opcional de esta página usa la Web Crypto API integrada en tu navegador. La decodificación y la verificación se realizan en tu dispositivo y no se sube nada. Como norma general, nunca pegues claves de firma de producción ni tokens en uso en sitios web en los que no confíes.
Preguntas frecuentes
¿Es seguro pegar un JWT en este decodificador?
El token se decodifica y se verifica con JavaScript en tu navegador y nunca se envía a un servidor. Ten en cuenta que un token que no ha caducado funciona como una contraseña para quien lo tenga, así que es preferible usar tokens de prueba o caducados cuando compartas capturas de pantalla o registros.
¿Puedo decodificar un JWT sin la clave secreta?
Sí. El encabezado y la carga útil son simplemente JSON codificado en Base64URL, así que se pueden leer sin ninguna clave. La clave secreta o la clave pública solo hacen falta para verificar la firma.
¿Por qué el decodificador dice que mi token ha caducado?
exp es anterior a la hora actual de tu dispositivo. Si el token todavía debería ser válido, revisa el reloj del sistema y la duración del token configurada por el emisor.¿Qué algoritmos de firma se pueden verificar?
HS256, HS384 y HS512 con una clave secreta compartida, y RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 y ES512 con una clave pública en formato PEM.
¿Qué significa "alg": "none"?
Indica un JWT sin proteger, con la firma vacía, tal como lo define RFC 7518. Cualquiera puede crear o modificar un token así, por lo que un servidor que espera tokens firmados siempre debe rechazarlo.