Qué revisar cuando falla la autenticación
Antes de atribuir un error de API al vencimiento, comprueba el destinatario. aud identifica a quién va dirigido el token y puede ser una cadena o un array. iss indica el emisor y sub, el sujeto al que se refiere. Un token destinado a otra API no sirve simplemente porque aún no haya vencido.
Los claims son afirmaciones incluidas en el token. Decodificarlos no confirma quién los escribió. Los campos obligatorios y los valores que se aceptan dependen de la aplicación o del protocolo que utilice.
Cabecera, payload y firma
Un JWT firmado habitual tiene tres partes: header.payload.signature. Las dos primeras contienen objetos JSON en UTF-8 codificados en Base64url. La última contiene bytes de firma o MAC; no es otro objeto JSON.
Puedes pegar el token solo, con Bearer o con Authorization: Bearer. No pegues la petición HTTP completa. Copia la cabecera y el payload por separado cuando necesites revisar los datos; los números grandes y la notación original se conservan en el JSON mostrado.
Cómo leer la fecha de expiración
exp marca el vencimiento, nbf el momento a partir del cual se permite usar el token e iat su emisión. Son valores NumericDate expresados en segundos desde el inicio de la época Unix. 1704067200 equivale al 1 de enero de 2024 a las 00:00 UTC. No lo confundas con milisegundos de JavaScript.
La tabla usa el reloj de tu dispositivo y no añade tolerancia por desfase. Que exp esté en el futuro no garantiza una firma auténtica ni un aud correcto. Una emisión futura se muestra como dato de diagnóstico; no provoca un veredicto general de validez.
Decodificar no es descifrar ni verificar
Base64url no oculta el contenido. Por eso puedes leer un JWT firmado sin conocer el secret. Para aceptarlo, tu aplicación debe verificar su protección criptográfica con claves de confianza y algoritmos permitidos, además de revisar los claims requeridos. No debe confiar únicamente en el alg que declara la entrada.
Esta herramienta no visita direcciones de claves ni usa claves integradas. No descifra JWE de cinco partes ni procesa JWT anidados o payloads b64: false. Admite hasta 50.000 caracteres y 64 niveles JSON; rechaza claves duplicadas para evitar lecturas ambiguas.
Ejemplos para probar
Token vencido
Datos ficticios y firma de ejemplo; no es una credencial utilizable.
Volver al decodificador JWT ↑Claims Unicode
Texto multilingüe y varios destinatarios; la firma es un marcador de posición.
Volver al decodificador JWT ↑Preguntas frecuentes
¿Necesito el secret para leer el payload?
No, siempre que sea un JWT de tres partes con payload JSON. Basta con decodificar Base64url. El secret o la clave pública se usa para la verificación criptográfica, que esta herramienta no realiza.
¿Qué significa alg: none?
Se trata de un token sin firma criptográfica. Conserva las tres partes, pero la última está vacía y el token termina en un punto. Eso no lo convierte en una credencial de confianza.
¿Se sube o se guarda el token?
La entrada se procesa en el navegador, no se envía a una API de decodificación, no se guarda mediante la herramienta y no se añade a la URL. Un Bearer real puede conceder acceso; para explorar las funciones puedes usar los ejemplos ficticios.
¿Los ejemplos tienen firmas válidas?
No. El ejemplo vencido tiene exp el 1 de enero de 2024 a las 01:00 UTC y una firma de relleno. El de Unicode muestra texto multilingüe y varios destinatarios, también con firma de relleno. El restante usa alg: none.
¿Por qué aparece un error de formato?
Revisa que haya tres segmentos y que los dos primeros sean objetos JSON UTF-8. Quita espacios, comillas y relleno. También se rechazan claves duplicadas y una firma vacía cuando alg no es none. Cinco partes pueden indicar un JWE cifrado, que no se descifra aquí.