Decodificador de JWT

¿Qué es un JWT?#

Un JWT (JSON Web Token, definido en RFC 7519) es un token compacto y seguro para URLs construido para transportar claims entre dos partes. Es la credencial que tu navegador envía a una API tras el inicio de sesión, la aserción de identidad que un proveedor OAuth entrega a una aplicación confiada y el envoltorio en el que viajan la mayoría de los flujos modernos de sesión y control de acceso. Su atractivo es que los claims (quién es el usuario, qué puede hacer, cuándo caduca el token) viajan dentro del propio token en formato JSON, así que el servicio receptor puede leerlos sin consultar una base de datos.

Un JWT tiene exactamente tres partes codificadas en base64url separadas por puntos: header.payload.signature. La cabecera (header) indica el algoritmo y el tipo de token. La carga útil (payload) es un objeto JSON de claims: los registrados como sub (sujeto), iat (emitido en), exp (caducidad), nbf (no antes de), más cualesquiera claims personalizados que añada tu aplicación. La firma (signature) es lo que el emisor calculó sobre las otras dos partes con un secreto o clave privada; verificarla es lo que prueba que el token no ha sido manipulado.

Esta página decodifica e inspecciona un JWT. Separa las tres partes, decodifica en base64url la cabecera y la carga útil a JSON legible, saca los claims temporales estándar como marcas de tiempo legibles por humanos y muestra una insignia de estado en vivo (Válido, Caducado, Aún no válido). Deliberadamente no verifica la firma: eso requiere el secreto o la clave pública del emisor y queda fuera del alcance de una herramienta 100 % del lado del cliente. El segmento de firma se muestra en bruto, exactamente como se recibió.

Cómo se usa#

1. Pega tu token en la caja de Entrada de la izquierda. Deben ser tres segmentos separados por puntos; los espacios en blanco alrededor se recortan automáticamente.
2. Pulsa Ejemplo para cargar un token de muestra incorporado (con iat/exp/nbf) si solo quieres ver cómo funciona la disposición.
3. Pulsa Limpiar para vaciar la entrada y los paneles de resultado.
4. Lee el panel derecho:
   • La insignia de estado de la parte superior (verde Válido, Caducado o Aún no válido), en función de los claims nbf y exp comparados con la hora actual.
   • La tarjeta Header, con el algoritmo mostrado en su barra de título (p. ej. HS256).
   • La tarjeta Payload, formateada como JSON.
   • La lista de claims temporales (Emitido, No antes de, Caduca), cada uno mostrado tanto como marca de tiempo Unix como como fecha legible.
   • El segmento de Signature, mostrado en bruto porque sigue siendo bytes codificados en base64url.
5. Si el token está mal formado, la línea de estado roja te dice si falló la comprobación de forma de tres segmentos, la decodificación base64url o el análisis JSON.

Características clave#

• Estado en vivo de los claims temporales. Lee iat, nbf y exp y te dice si el token es actualmente válido, ya ha caducado o aún no está en vigor: las tres preguntas que de verdad te haces durante un bug de login.
• Fechas legibles por humanos. Números de época Unix como 1700000000 se muestran junto a la fecha UTC que representan, para que dejes de hacer aritmética mental de épocas.
• Algoritmo a la vista. El valor alg de la cabecera se lleva a la barra de título de la tarjeta Header, así ves de inmediato si tienes entre manos un HS256, un RS256 o algo inesperado.
• Decodificación segura con UTF-8. Los segmentos base64url se decodifican a bytes a través de TextDecoder, así que los claims no ASCII (nombres, roles en otras escrituras) se renderizan correctamente en vez de como mojibake.
• Solo decodifica, nunca verifica. La herramienta nunca pide un secreto, lo que la hace segura para pegar tokens en los que no confías plenamente: nada se envía a ningún sitio y la firma se muestra, pero no se comprueba.

Ejemplo práctico#

Pulsa Ejemplo y la entrada se rellena con un token cuya cabecera se decodifica a:

{
  "alg": "HS256",
  "typ": "JWT"
}

y cuya carga útil se decodifica a:

{
  "sub": "1234567890",
  "name": "ArpGate Demo",
  "iat": 1700000000,
  "exp": 4102444800,
  "nbf": 1699999000
}

La lista de claims temporales muestra entonces:

Issued at   1700000000  (2023-11-14 22:13:20 UTC)
Not before  1699999000  (2023-11-14 21:56:40 UTC)
Expires     4102444800  (2100-01-01 00:00:00 UTC)

La insignia de estado marca Válido, porque la hora actual es posterior a nbf y anterior a exp. El segmento de firma se muestra como la cadena literal c2FtcGxlLXNpZ25hdHVyZS1ub3QtdmVyaWZpZWQ, que se decodifica al texto «sample-signature-not-verified», un marcador deliberado de que la firma de este token es ilustrativa, no una salida HMAC-SHA256 real.

Ese último punto es lo más importante que hay que entender de esta herramienta: un token que se decodifica limpiamente no es necesariamente un token fiable. Cualquiera puede falsificar la cabecera y la carga útil; solo la firma, comprobada contra el secreto o la clave pública del emisor, prueba la autenticidad. Usa esta página para leer los claims y depurar ventanas temporales; verifica las firmas en tu backend real.

Preguntas frecuentes#

¿Puede esta herramienta decirme si un JWT es auténtico?#

No, y es por diseño. Decodificar se limita a leer el JSON dentro del token: no prueba que el token lo emitiera quien dice haberlo emitido. Para verificar la autenticidad necesitas la clave apropiada al alg (un secreto compartido para HS256, la clave pública del emisor para RS256/ES256) y una rutina de verificación en un backend de confianza. Nunca trates un token decodificado limpiamente como un token verificado.

El estado dice «Caducado». ¿Puedo refrescar el token aquí?#

No. Refrescar significa llamar al endpoint de refresco de tu servidor de autenticación para obtener un nuevo token de acceso: una operación de red que esta página estática y del lado del cliente no puede ni debe realizar. Lo que sí puedes hacer aquí es confirmar exactamente cuándo caducó el token antiguo, que suele ser la pista que necesitabas.

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

iat (issued at, emitido en) es cuándo se creó el token: informativo. nbf (not before, no antes de) es la hora más temprana en la que debería aceptarse el token; antes de nbf, un servidor validador debería rechazarlo aun cuando la firma sea válida. exp (expiration, caducidad) es el corte duro a partir del cual el token debe rechazarse. Un token bien formado tiene nbf ≤ iat ≈ ahora y exp en algún punto del futuro próximo (minutos para tokens de acceso, más para tokens de refresco).

Mi carga útil contiene caracteres no ASCII y en otros sitios se ven revueltos. ¿Por qué aquí se ven bien?#

Porque algunos decodificadores tratan por error cada carácter base64url como un byte, en vez de decodificar primero a bytes en bruto. Esta página decodifica a un Uint8Array y luego lo pasa por TextDecoder, que interpreta los bytes como UTF-8 correcto. Esa es la forma correcta, y por eso los nombres, roles y scopes en cualquier escritura se renderizan tal como se escribieron.