Decodificador JWT
Pega un token JWT para ver el header, el payload y la firma, saber si sigue vigente y revisar sus roles y scopes. Se decodifica mientras lo pegas.
El token, el secreto y la clave pública se quedan en tu navegador. Nada de eso se envía a ningún servidor, tampoco al nuestro, y desaparece al cerrar la página.
Todavía no hay token
Pega un JWT en el campo. El estado, las fechas y los claims aparecen aquí al instante.
¿Necesitas un token con otros claims, como un admin y un usuario común?
¿Cómo usar el Decodificador JWT?
Pega el token
Cópialo de DevTools, de Postman o de un log y pégalo. Bearer, comillas y saltos de línea se quitan solos.
Mira el estado
El estado indica si el token caducó, cuándo caduca y a qué hora, en tu zona horaria y en UTC.
Comprueba la firma
Introduce el secreto o la clave pública para saber si el token es auténtico y no fue modificado.
Copia lo que necesites
Copia el token limpio, el header, el payload o el valor de un claim con un clic.
¿Qué es un JWT?
Un JWT (JSON Web Token, RFC 7519) es un formato de token para pasar información entre sistemas, sobre todo en el login y la autorización de APIs. El servidor de autenticación emite el token después del login, la aplicación lo envía en cada petición y la API lee sus claims para saber quién es el usuario y qué puede hacer.
Las tres partes de un JWT
Un JWT tiene tres bloques en base64url separados por puntos:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsInJvbGVzIjpbInVzZXIiXX0.3mG4X8mY2bJqS0mY7fUv0M1wS6Qy0p2WmH0x0J3bQKc- Header. El header indica qué algoritmo firmó el token (alg) y a veces qué clave se usó (kid).
- Payload. El payload lleva los claims: quién es el usuario, cuándo caduca el token, para qué API sirve y qué permisos concede.
- Firma. La firma se calcula sobre el header y el payload. Si cambia un solo carácter, deja de coincidir.
Por qué se puede leer el payload sin contraseña
El header y el payload solo están codificados en base64url, una variante de Base64 que cambia + y / por - y _ y quita el = final. Codificar no es cifrar: cualquiera que tenga el token puede leer su contenido, que es justo lo que hace esta herramienta. Por eso nunca pongas contraseñas, números de tarjeta ni datos sensibles en el payload de un JWT.
Claims registrados y claims personalizados
La RFC 7519 define siete claims registrados: iss, sub, aud, exp, nbf, iat y jti. Tienen nombres cortos y un significado fijo, y las bibliotecas de JWT validan exp, nbf y aud automáticamente. El resto son claims personalizados, creados por la aplicación o el proveedor de identidad, como roles, scope, email o realm_access en Keycloak. En la tabla de claims, cada claim conocido viene con una explicación breve.
Decodificar no es validar
Leer el payload no demuestra nada sobre el token. Cualquiera puede armar un JWT con un sub de admin y un exp dentro de diez años. La autenticidad la da la firma, y quien debe verificarla es el backend, siempre con el algoritmo fijado en su configuración en lugar de lo que diga el header. Usa la verificación de esta página para depurar, nunca como sustituto de la validación en el servidor.
El riesgo de alg none
El valor "none" en alg indica un token sin firma. Algunas bibliotecas antiguas aceptaban estos tokens cuando el header lo pedía, así que a un atacante le bastaba con cambiar el alg y borrar la firma para hacerse pasar por cualquier usuario. Cuando esta herramienta encuentra alg none, muestra un aviso. Si tu API acepta un token así, trátalo como un fallo de seguridad.
JWS y JWE: firmado o cifrado
Casi todos los JWT que circulan son JWS: firmados, con tres partes y un payload legible. El JWE es la versión cifrada, con cinco partes, y solo puede leerlo quien tiene la clave de descifrado. Si pegas un JWE aquí, la herramienta te avisa y muestra solo el header, que sigue siendo legible.
Dónde encontrar el token para pegarlo aquí
- En el header Authorization: Bearer de una petición, en la pestaña Network de DevTools o en Postman e Insomnia
- En una cookie de sesión, en la pestaña Application de DevTools (la cookie puede ser HttpOnly e invisible para JavaScript)
- En la respuesta del endpoint de token del proveedor, en los campos access_token e id_token
- En logs del API gateway y de la aplicación, muchas veces partido en varias líneas
Problemas comunes al depurar login y permisos
El login falla con 401 al cabo de un rato
El estado muestra si el exp ya pasó y hace cuánto. Si el token caduca en pocos minutos, comprueba que el front usa el refresh token para pedir uno nuevo.
Un usuario con sesión recibe 403
Mira el bloque de roles y scopes. Si falta el rol esperado, el problema está en la configuración del proveedor o en el tipo de token que se envía (enviar el ID token en lugar del access token es un error común).
Token rechazado justo después de emitirse
exp, iat y nbf cuentan segundos en UTC y no dependen de la zona horaria. Cuando se rechaza un token recién emitido, la causa suele ser un desfase de reloj entre servidores. Las fechas aparecen en tu hora y en UTC para compararlas con los logs.
Token válido rechazado por otra API
Revisa el aud. Cada API debe aceptar solo los tokens emitidos para ella, así que el token de una API no sirve para otra.
Preguntas Frecuentes sobre el Decodificador JWT
Lo que suele surgir al leer y depurar tokens JWT.