Encoders & Utilities

Decodificador JWT

Decodifica header y payload de un JWT de forma local.

JWT token Paste a JWT — we will split it into header, payload, and signature.

Sobre esta herramienta

Un JSON Web Token (RFC 7519) son tres segmentos codificados en Base64url unidos por puntos: header, payload y signature. JWT Decoder divide el token, decodifica los dos primeros segmentos a JSON, los formatea y calcula los claims relacionados con el tiempo (iat, exp, nbf) como timestamps legibles. Los claims registrados estándar (iss, sub, aud, jti) se etiquetan con su significado. La decodificación corre íntegramente en su navegador — su token nunca sale de la página.

El header le dice el algoritmo de firma (alg: HS256, RS256, ES256, etc.) y el kid opcional (key ID). El payload contiene los claims de la aplicación — id de usuario, roles, expiración. La firma se muestra como un blob Base64; deliberadamente no la verificamos en esta página porque verificar requiere el secreto o la clave pública del emisor, que nunca debería pegarse en una herramienta de terceros. El token se trata solo como datos.

Cuándo utilizar esta herramienta

Leer un token de su propio servicio. Inspeccione qué claims emite realmente — detecte rápidamente campos faltantes, audiencias incorrectas o valores por defecto sorprendentes.
Depurar respuestas «401 Unauthorized». Compruebe expiración, emisor, audiencia y scope contra lo que espera el servidor.
Verificar una integración de terceros. Cuando un proveedor OAuth le entrega un ID token, decodifique el payload para ver qué claims de usuario incluye.
Detectar confusión de algoritmo. Si alg es none o difiere inesperadamente entre tokens, su biblioteca de auth probablemente está mal configurada.

Por qué no validamos firmas

La verificación de firma JWT requiere el secreto (para algoritmos HMAC) o la clave pública del emisor (para RSA/ECDSA). Pegar cualquiera de los dos en una herramienta web es un error de seguridad — el secreto comprometería todos los tokens emitidos; la clave pública, aunque menos sensible, aún puede ser privada. El decoder confirma la estructura y revela los claims; para verificación real, use el SDK que viene con su biblioteca de auth (jsonwebtoken, pyjwt, jose) dentro de su propio código.

Preguntas frecuentes

¿Es seguro pegar mi JWT aquí?

La decodificación ocurre íntegramente en JavaScript en su navegador — no se hace ninguna llamada de red, no se registra nada en el servidor. Dicho esto, los JWT en producción deberían tratarse como credenciales: no pegue un token de larga vida de un servicio que no controle en ninguna herramienta de terceros, incluida la nuestra. Para tokens de dev/staging o tokens expirados, decodificar aquí está bien.

¿Por qué se muestra la firma pero no se verifica?

Porque verificar requiere la clave de firma, y pegar una clave de firma en una herramienta web sería un error serio. La firma se muestra como Base64 para que pueda ver que existe y tiene la longitud adecuada para el algoritmo, pero validar realmente contra un secreto HMAC (HS256) o una clave pública (RS256/ES256) pertenece dentro de su aplicación, no en una herramienta del navegador.

¿Qué significa «alg: none»?

Un JWT sin firmar. El header dice explícitamente que no se aplicó algoritmo, así que el segmento de firma está vacío. alg: none existe en la especificación pero nunca debería aparecer en producción — es la causa raíz de la famosa vulnerabilidad «JWT none-algorithm» en la que una biblioteca acepta none como válido. Si lo ve en un token real de un servicio real, es un bug serio.

¿Cuál es la diferencia entre exp, iat y nbf?

iat (issued-at) es cuándo se creó el token. nbf (not-before) es la fecha más temprana en la que se puede usar el token — normalmente igual a iat pero puede estar en el futuro para activación retardada. exp (expiration) es cuándo el token deja de ser válido. Los tres son timestamps Unix en segundos. Un verificador correcto comprueba nbf ≤ ahora ≤ exp en cada petición.