Decodificador de JWT
Cómo funciona
Pega cualquier JWT, esa cadena larga xxx.yyy.zzz que ves en las cabeceras Authorization: Bearer, en respuestas OAuth, en cookies o en los tokens de autenticación de Firebase. La herramienta lo divide en sus tres partes (header, payload y firma), decodifica en Base64URL las dos primeras a JSON y las muestra una junto a otra con resaltado de sintaxis. La tercera parte se muestra tal cual, porque una firma es binaria, no texto decodificable.
El header te dice qué algoritmo firmó el token (alg) y a veces qué clave se usó (kid). Valores habituales: HS256 (HMAC-SHA-256, simétrico), RS256 (RSA-SHA-256, asimétrico, el predeterminado en OAuth / OpenID Connect), ES256 (ECDSA P-256, lo que prefieren Apple y los emisores modernos) y el infame "none", que significa sin firmar y que siempre debe rechazarse.
El payload lleva los claims, los datos reales del token. Claims estándar que la herramienta resalta: • `iss`: emisor (qué servicio generó el token) • `sub`: sujeto (normalmente el ID del usuario) • `aud`: audiencia (qué servicio puede consumirlo) • `exp`: caducidad, una marca de tiempo Unix; la herramienta la convierte en una fecha legible y una etiqueta "caduca en 23 minutos", o "CADUCADO hace 2 horas" si ya pasó • `iat`: marca de tiempo de emisión • `nbf`: no válido antes de (el token no vale antes de ese momento) • `jti`: un ID único del token, que sirve para revocar tokens concretos
Todo lo demás son claims propios (roles, permisos, ID de inquilino, correo). La herramienta conserva el orden y los tipos exactos del JSON, así que puedes comprobar a simple vista lo que emite de verdad tu servidor de autenticación.
Una advertencia de seguridad que conviene tomarse en serio: NO pegues un JWT de producción en una herramienta en línea que no controles. Los JWT pueden contener datos personales (correo, ID de usuario), identificadores de sesión y permisos de acceso. Incluso una herramienta de solo lectura que envíe el token a un servidor acaba de recibir, registrar y quizá guardar tus credenciales. Esta herramienta decodifica dentro de la página, algo que puedes comprobar en la pestaña Red de las herramientas para desarrolladores viendo que no sale ninguna petición, pero para depurar en producción prefiere, cuando puedas, la CLI `jwt` o una extensión local del IDE.
Preguntas frecuentes
¿Es seguro pegar aquí mi JWT?
- Más que en la mayoría de los decodificadores en línea, porque este se ejecuta por completo en tu navegador: pegar y decodificar no lanza ninguna petición de red, algo que puedes comprobar en la pestaña Red de las herramientas para desarrolladores. Dicho esto, para tokens de producción con un identificador de sesión activo lo más seguro es siempre una CLI local o la extensión JWT de tu IDE. Cualquier token válido pegado en cualquier página web es una posible fuga de credenciales si la página o una extensión del navegador está comprometida.
¿Verifica la firma?
- No, esta herramienta solo decodifica. La verificación de la firma necesita el secreto de firma (HS256) o la clave pública del emisor (RS256 / ES256), y ninguno de los dos debe estar en una herramienta web cualquiera. Decodificar es leer en un solo sentido; verificar es otro paso, que se hace mejor en el servidor o con una librería específica (jose, jsonwebtoken, pyjwt).
¿Qué claims muestra?
- Todos los claims del payload, con resaltado especial para los estándar registrados: iss (emisor), sub (sujeto), aud (audiencia), exp (caducidad, mostrada como fecha legible más una etiqueta de caduca en), iat (emitido en), nbf (no válido antes de) y jti (ID del token). Los claims propios (roles, inquilino, correo, permisos) aparecen debajo en su orden original.
¿Por qué mi token tiene tres partes separadas por puntos?
- Porque un JWT tiene exactamente tres partes: header.payload.signature, cada una codificada en Base64URL. El header y el payload se decodifican a JSON; la firma es un MAC o una firma binaria que no se puede decodificar a texto legible. Si tu token tiene más o menos puntos, no es un JWT estándar, posiblemente sea un JWE (la variante cifrada, que esta herramienta no admite).
Mi JWT tiene "alg":"none", ¿es peligroso?
- Sí, y fue históricamente una vulnerabilidad grave. alg:none significa que el token no está firmado, y cualquier aplicación que lo acepte sin más se creerá tokens falsificados. Las librerías modernas rechazan alg:none por defecto. Verlo en un token de un servicio en producción es una señal de alarma: el emisor nunca debería emitir tokens sin firmar.
¿Qué diferencia hay entre HS256 y RS256?
- HS256 es simétrico (HMAC con un secreto compartido): rápido, pero quien puede verificar también puede firmar. RS256 es asimétrico (un par de claves RSA): el emisor firma con la clave privada y los consumidores verifican con la pública. OAuth y OpenID Connect usan RS256 (o ES256) precisamente porque la clave pública se puede distribuir sin riesgo. Usa HS256 solo para tokens internos de un mismo servicio, donde tiene sentido un secreto compartido.
¿Cómo compruebo si mi JWT ha caducado?
- Mira la etiqueta: "caduca en 23 minutos" en verde mientras el token sigue siendo válido, "CADUCADO hace 2 horas" en rojo cuando ya no. La etiqueta sale del claim `exp`, una marca de tiempo Unix en segundos, y el token ha caducado cuando `exp < Date.now() / 1000`. Un token sin claim `exp` no caduca nunca, lo que suele ser un error de configuración, porque casi todos los emisores deberían poner uno.
¿Puedo decodificar un JWT en Node, Python o con curl?
- Sí, en una línea cada uno. Node: `Buffer.from(token.split('.')[1], 'base64url').toString()`. Python: `import base64,json; json.loads(base64.urlsafe_b64decode(token.split('.')[1] + '=='))`. Bash: `echo $TOKEN | cut -d. -f2 | base64 -d | jq` (añade el relleno `=` si hace falta). Los tres decodifican solo el payload; para verificar usa jose (Node), pyjwt (Python) o una CLI como jwt-cli.
¿Qué diferencia hay entre JWT y JWE?
- Un JWT (JSON Web Token, RFC 7519) está firmado: el payload va codificado en Base64 y lo puede leer cualquiera, ya que la firma solo prueba quién lo emitió. Un JWE (JSON Web Encryption, RFC 7516) está cifrado: el payload es ilegible sin la clave de descifrado. Los JWT tienen tres partes (header.payload.signature), los JWE cinco (header.encryptedKey.iv.ciphertext.tag). Esta herramienta decodifica solo JWT; un JWE necesita la clave privada del destinatario y no puede abrirlo una herramienta web genérica.
Algoritmos de firma de JWT: cuál usar y cuándo
El campo `alg` del header de un JWT te dice cómo se firmó el token. Referencia rápida de los algoritmos que te encontrarás en tokens de producción.
| alg | Tipo | Material de clave | Uso típico | Notas |
|---|---|---|---|---|
| HS256 | HMAC-SHA-256 (simétrico) | Secreto compartido ≥ 32 bytes | Tokens internos de un mismo servicio, apps de un solo inquilino | Rápido. Quien puede verificar también puede firmar, así que nunca distribuyas el secreto |
| HS384 | HMAC-SHA-384 (simétrico) | Secreto compartido ≥ 48 bytes | Igual que HS256 con un hash más fuerte | Raro. HS256 basta para casi todos los casos |
| HS512 | HMAC-SHA-512 (simétrico) | Secreto compartido ≥ 64 bytes | Tokens simétricos de alta seguridad | Raro |
| RS256 | RSA-PKCS1-v1_5 + SHA-256 | Par de claves RSA (mínimo 2048 bits) | OAuth 2.0, OpenID Connect, API públicas | Predeterminado en Auth0, Okta, AWS Cognito y Firebase. La clave pública se puede compartir mediante JWKS |
| RS384 | RSA-PKCS1-v1_5 + SHA-384 | RSA 2048+ | Como RS256 con un hash más fuerte | Poco usado |
| RS512 | RSA-PKCS1-v1_5 + SHA-512 | RSA 2048+ | Como RS256 con un hash más fuerte | Poco usado |
| ES256 | ECDSA P-256 + SHA-256 | Par de claves EC P-256 | OAuth moderno, apps móviles, Sign in with Apple | Firmas más pequeñas (64 bytes frente a los 256+ de RSA). Lo que prefieren la mayoría de los emisores modernos |
| ES384 | ECDSA P-384 + SHA-384 | Par de claves EC P-384 | ECDSA de alta seguridad | Poco usado |
| ES512 | ECDSA P-521 + SHA-512 | Par de claves EC P-521 | ECDSA de muy alta seguridad | Poco usado |
| EdDSA | Ed25519 (o Ed448) | Clave Ed25519 de 32 bytes | Alternativa más nueva a ECDSA: rápida y de tiempo constante | Cada vez más usado. Compatible con jose, jsonwebtoken (con plugins) y pyjwt 2.6+ |
| PS256 | RSA-PSS + SHA-256 | RSA 2048+ | Relleno RSA más seguro que RS256 | Algunas especificaciones (FAPI) lo recomiendan frente a RS256. Comprueba que tu librería lo admita |
| none | (sin firmar) | (ninguno) | Solo para depuración | NUNCA lo aceptes en producción: fue una vulnerabilidad grave (CVE-2015-9235). Recházalo de forma explícita |
Definidos por la RFC 7518 (JOSE / JWA). La mayoría de los proveedores de identidad usan RS256 por defecto; las pilas modernas (Apple, Firebase, las apps más nuevas de Auth0) usan cada vez más ES256 o EdDSA por tokens más pequeños y mejor rendimiento en móvil.