Decodificar un JWT (leer el token)
Vea el header y el payload de un JWT como JSON formateado; exp e iat se convierten en fechas legibles
Sus datos se quedan con usted. La conversión ocurre dentro del navegador; no se envía nada a ningún servidor.
¿Le sirvió esta herramienta?
Gracias, su comentario llegó.
Cómo funciona
Pegue el token en el panel izquierdo tal como lo copió: si arrastró un prefijo Bearer o Authorization:, la herramienta lo quita sola, y un token partido en varias líneas se vuelve a unir. La salida muestra tres bloques: el header (algoritmo y tipo), el payload (los campos que lleva el token) y los campos de tiempo. Un payload con "exp": 1817121600, por ejemplo, aparece acompañado de la fecha de calendario que le corresponde y de si ese plazo ya venció o no; iat (emitido el) y nbf (no válido antes de) se convierten igual, en la zona que usted elija — UTC o un desfase fijo de UTC+3. El token no se envía a ningún servidor; por eso examinar un token real de un sistema donde tiene sesión abierta no lo saca de su equipo. Lo que la herramienta no hace, a propósito, es verificar la firma: leer el contenido no demuestra que esté intacto — la verificación exige la clave secreta, y una clave secreta no se pega en ninguna página web.
Esta herramienta también se busca como decodificar jwt, leer token jwt, jwt decoder online, jwt decode.
¿Qué es JWT (JSON Web Token)?
El JWT es un formato de texto en tres partes que transporta identidad y permisos entre dos sistemas: el header nombra el algoritmo, el payload lleva los campos y la firma acredita que el contenido no fue alterado. Las partes van separadas por puntos y cada una está codificada en Base64URL — el contenido va empaquetado, no cifrado. Tras iniciar sesión, el servidor entrega un JWT al usuario; en las peticiones siguientes lo reconoce verificando la firma en lugar de consultar una base de datos. Ese diseño hace portátil al token, con un precio: quien lo tenga puede actuar con esa identidad hasta que expire.
¿Qué es Base64URL?
Base64URL es una codificación que traslada los datos a un alfabeto seguro de letras, dígitos, guion y guion bajo; los caracteres + y / del Base64 clásico tienen significado propio en una dirección web, así que dejan su sitio a - y _, mientras que el relleno final con = ni siquiera se escribe. Las tres partes de un JWT usan esta codificación — por eso un token sobrevive intacto en la barra de direcciones, en una cookie o en una cabecera HTTP. Codificar no es cifrar: cualquier herramienta deshace el camino sin necesidad de clave, y eso es exactamente lo que hace esta página.
¿Qué diferencia hay entre decodificar y verificar un JWT?
Decodificar es deshacer la codificación Base64URL y leer lo que dicen el header y el payload; no hace falta clave, cualquiera puede hacerlo, y eso hace esta herramienta. Verificar es calcular si la firma, el contenido y la clave secreta encajan entre sí: cambie un solo carácter del contenido, o firme con otra clave, y la verificación falla. La diferencia es crítica para la seguridad — un token decodificado solo dice qué se afirma; un token verificado demuestra que esa afirmación la firmó quien tiene la clave. En el lado del servidor nunca basta con decodificar: la firma se verifica en cada petición.
No confíe en el contenido decodificado: la firma no se verificó
Las dos primeras partes de un JWT no van cifradas, solo codificadas en Base64URL; esa codificación es un sobre, no un candado, y cualquiera puede abrirlo. La confianza viene de la tercera parte, la firma — un resumen matemático del contenido y de una clave secreta, que solo puede verificar quien tiene la clave.
Esta herramienta se salta la verificación a propósito: hacerla aquí supondría pegar su clave secreta en una página web, y una clave de producción no se pega en ningún sitio web, incluido este. Lo que ve responde a la pregunta de qué afirma el token; si el token es auténtico solo puede responderlo su servidor, contrastando la firma con la clave.
¿Qué significan los campos del payload?
La RFC 7519 estandariza unos pocos nombres de campo; el resto depende de cada aplicación. Estos son los que verá con más frecuencia:
- sub → el titular del token (casi siempre el identificador del usuario)
- iss → el sistema que emitió el token (issuer)
- aud → el sistema al que va destinado el token (audience)
- exp → momento de expiración; pasado ese punto, el servidor rechaza el token
- iat → momento de emisión; la distancia hasta exp es la vida del token
- nbf → no válido antes de ese momento (tokens posfechados)
Preguntas frecuentes
¿Cómo se decodifica un JWT?
Pegue el token en el panel izquierdo — nada más. El header y el payload se abren al instante como JSON formateado, y los campos de tiempo como exp e iat se convierten en fechas legibles. Sin instalación y sin clave.
¿Mi token se envía a algún servidor?
No. Todo el trabajo de decodificar corre dentro de su navegador y el token no se transmite a ninguna parte. Aun así, tenga cuidado: un token de producción todavía vigente abre sesión a quien lo tenga en la mano — cierre la página cuando termine.
¿Esta herramienta verifica la firma?
No, y es a propósito. La verificación exige la clave secreta, y una clave secreta nunca debe pegarse en una página del navegador. La herramienta solo muestra el contenido; que el token salió de verdad de su servidor solo puede confirmarlo su servidor.
¿Cómo sé si el token ya expiró?
Si el payload trae el campo exp, la herramienta lo convierte en fecha y escribe al lado si el plazo venció o no. La comparación usa el reloj de su equipo — si ese reloj está mal, el veredicto también.