Cómo se usa
Al pegar un token en «Pega un JWT» salen estos cinco bloques:
- Aviso de caducidad: si el payload trae exp, arriba del todo aparece «Sin caducar» o «Caducado» junto a la fecha y hora de exp. Este aviso solo compara exp con el reloj del dispositivo; no confirma la hora de inicio nbf ni verifica la firma.
- Header y Payload: cada parte como JSON indentado. El botón que hay junto a cada título copia esa parte por separado.
- Algoritmo de firma: el valor de alg del header. Si falta o no es una cadena de texto, pone «No indicado».
- Signature (tal cual, sin verificar): el tercer fragmento del token, sin tocar.
- Claims registrados: exp (caduca el), iat (emitido el) y nbf (válido a partir de), pasados a fecha y hora. Los que no están en el payload aparecen como «No presente».
Las fechas y horas salen en la zona horaria de este navegador. Si los registros del servidor están en UTC, las verás desplazadas tantas horas como haya de diferencia.
Un ejemplo para leerlo paso a paso
Prueba a pegar este token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwiaWF0IjoxNzY3MjI1NjAwLCJleHAiOjE3NjcyMjkyMDB9.c2lnbmF0dXJl- El Header es
{"alg": "HS256", "typ": "JWT"}y el algoritmo de firma, HS256. - El Payload es
{"sub": "user-42", "iat": 1767225600, "exp": 1767229200}. - El iat 1767225600 corresponde al 1 de enero de 2026 a las 00:00:00 (UTC), y el exp 1767229200, a una hora más tarde, las 01:00:00 (UTC). En un navegador con una zona horaria UTC+9 se muestran como las 9:00:00 y las 10:00:00 de la mañana. Como esa hora ya pasó, el aviso de arriba dice «Caducado».
- El tercer fragmento,
c2lnbmF0dXJl, no es una firma de verdad: es la palabra signature escrita en Base64URL. Aun así, el token se decodifica sin ningún error, y eso deja claro que esta herramienta no comprueba la firma en absoluto.
Las tres partes de un JWT
Un JWT son tres fragmentos separados por puntos (header.payload.signature). El header indica el algoritmo de firma (alg) y el tipo de token (typ); el payload lleva los claims, como el identificador del usuario, sus permisos o la hora de caducidad. Un claim es, sencillamente, un par de nombre y valor que viaja dentro del token.
El header y el payload son JSON pasado a Base64URL, nada más: no están cifrados. Quien tenga el token puede leer su contenido sin ninguna clave, de modo que pegar en un chat o en un gestor de incidencias un token con correos electrónicos o permisos internos equivale a publicar esos datos. Solo el último fragmento, la signature, se calcula con la clave del emisor, y sirve para comprobar que el header y el payload no han cambiado desde que se emitió el token.
Lo que esta herramienta no comprueba
- La firma: para verificarla hace falta la clave secreta del emisor (familia HMAC) o su clave pública (familias RSA y ECDSA), y aquí no hay ningún campo donde introducir una clave. Que el contenido se vea correcto no significa que el token sea auténtico.
- El reloj con el que se decide la caducidad: «Sin caducar» y «Caducado» salen de comparar con el reloj de este dispositivo. Si el reloj va mal, el resultado también.
- El margen de tolerancia: el token pasa a «Caducado» en el mismo instante en que la hora actual alcanza el exp, y aparece como «Antes de la hora de inicio» mientras sea anterior al nbf. El RFC 7519 admite un pequeño margen, normalmente de no más de unos minutos, para absorber las diferencias de reloj entre servidores; esta herramienta no deja ninguno. Por eso un token que tu servidor todavía acepta puede verse aquí como caducado.
- Los demás claims: valores como iss (emisor) o aud (destinatario) se muestran tal cual en el Payload, sin comprobar si son los que deberían ser.
El control de acceso real depende de la verificación que hace el servidor. Y un token de producción, mientras no caduque, funciona como una tarjeta de acceso: lo prudente es hacer caso a la advertencia de la pantalla y no pegarlo en herramientas en línea.
Cómo leer los valores de exp, iat y nbf
El RFC 7519 establece que estos tres claims se escriben como el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 (UTC). Ese formato se llama NumericDate. La herramienta solo convierte el valor en fecha cuando es un número.
- Si es una cadena entre comillas, como
"exp": "1767229200", no se lee como fecha y aparece «No presente». En el JSON del Payload el valor sigue ahí, así que, si el claim existe y aun así pone «No presente», mira las comillas. - También aparece «No presente» cuando el número es tan grande que JavaScript no puede representarlo como fecha.
- Solo exp y nbf llevan estado. De iat se muestra únicamente la fecha y la hora.
Si el token no se decodifica
| Error que aparece | Causa habitual |
|---|---|
| Un JWT debe tener tres partes separadas por puntos (header.payload.signature), pero este tiene N | Se ha copiado solo un trozo del token. Los tokens cifrados (JWE) tienen cinco fragmentos y esta herramienta no puede leerlos |
| La parte “header” (o “payload”) no se pudo leer como Base64URL | Lleva «Bearer » delante, tiene un salto de línea en medio o es Base64 corriente, con +, / o = |
| La parte “header” (o “payload”) se decodificó, pero no es JSON válido | No es un JWT, sino otros valores unidos con puntos |
Base64URL es la variante de Base64 que cambia + y / por - y _ y suprime los = del final. La herramienta no decodifica nada que contenga caracteres distintos de A–Z, a–z, 0–9, - y _.