Decodificador JWT

Los JSON Web Tokens son el mecanismo de autenticación más extendido en APIs REST modernas, pero su estructura en Base64URL los hace completamente ilegibles a simple vista. Este decodificador desglosa el header, el payload y las fechas <code>iat</code>/<code>exp</code> en formato legible, directamente en el navegador sin enviar el token a ningún servidor.

Anatomía de un JWT: header, payload y firma

Decodificar un JWT no equivale a verificarlo: la decodificación muestra el contenido en texto legible, pero solo el servidor con la clave secreta puede confirmar que el token es auténtico y no ha sido manipulado.

Un JWT tiene tres partes separadas por puntos (xxxxx.yyyyy.zzzzz). El header contiene el algoritmo de firma (típicamente HS256, RS256 o ES256) y el tipo (JWT). El payload contiene los claims: datos del usuario como sub (subject/user ID), email, roles, y los timestamps iat (issued at) e exp (expiration). La firma es un hash criptográfico que solo puede verificarse con la clave secreta del servidor.

Decodificar el header y el payload es trivial (solo requiere decodificación Base64URL) y no revela ningún secreto. La clave nunca forma parte del token. Lo que sí puede ser sensible es el contenido del payload: IDs de usuario, permisos o datos personales, razón por la cual este decodificador opera 100 % localmente.

Interpretar iat y exp: timestamps Unix

Los campos iat y exp son timestamps Unix (segundos desde el 1 de enero de 1970 UTC). Un valor típico de expiración para tokens de sesión es 3,600 (1 hora), 86,400 (24 horas) o 604,800 (7 días) sumados al iat. Este decodificador convierte ambos a fecha y hora legible en tu zona horaria local y muestra si el token ya expiró.

Un token expirado devolverá 401 Unauthorized en la API. Si ves que el exp ya pasó pero la app sigue funcionando, probablemente el servidor no está validando la expiración correctamente —un bug de seguridad a reportar.

• ▸Header típico: {"alg":"HS256","typ":"JWT"}
• ▸Claims estándar: sub, iss, aud, exp, iat, nbf, jti
• ▸HS256 usa clave simétrica (mismo secreto para firmar y verificar); RS256 usa par público/privado
• ▸El payload puede contener cualquier dato JSON personalizado; no hay cifrado, solo codificación Base64URL

Casos de uso: debugging en desarrollo y auditoría de seguridad

Durante el desarrollo de una API, esta herramienta es útil para verificar que el backend está incluyendo los claims correctos (roles, permisos, tenant ID) sin necesidad de conectar un debugger. También sirve para confirmar que el tiempo de expiración configurado en el servidor es el esperado.

En auditorías de seguridad, inspeccionar JWTs interceptados (en pruebas de penetración autorizadas) permite verificar si se están almacenando datos sensibles innecesariamente en el payload: contraseñas en texto plano, datos de tarjetas o información médica nunca deben aparecer en un JWT sin cifrado adicional.

Cómo funciona — paso a paso

1. 1
   Pega el JWT

   Copia el token de tu aplicación (del header Authorization, de localStorage o de una cookie) y pégalo en el campo de entrada.
2. 2
   Lee el header y el payload

   La herramienta muestra el algoritmo de firma y todos los claims en formato JSON indentado.
3. 3
   Verifica las fechas

   Comprueba que iat y exp tienen los valores esperados y si el token está vigente o expirado.
4. 4
   Diagnostica el problema

   Si el contenido del payload no incluye los campos que espera tu frontend, el bug está en cómo el backend genera el token.