Decodificador JWT

Decodifica un JSON Web Token para leer su header y payload.

100 % privado — funciona totalmente en tu navegador. Tus datos se procesan en tu dispositivo y nunca se envían a Internet.

Header
Payload

Acerca del decodificador JWT

Este decodificador JWT gratuito lee un JSON Web Token y muestra su encabezado y su carga útil como JSON formateado, con las horas de emisión y de caducidad convertidas en fechas legibles.

La decodificación ocurre en su navegador — su token nunca se sube. No es un detalle menor: un JWT suele ser una credencial activa, y pegar uno en un sitio web que lo envía a algún sitio equivale a entregar todo el acceso que contiene.

Esta herramienta decodifica un token. No verifica la firma — más abajo se explica por qué esa distinción importa.

Las tres partes de un token

Un JWT son tres bloques de Base64url separados por puntos:

xxxxx.yyyyy.zzzzz

Encabezado — qué algoritmo firmó el token y de qué tipo es. Normalmente dos campos: alg y typ.

Carga útil — las reclamaciones (claims). A quién se refiere el token, quién lo emitió, cuándo caduca y todo lo demás que la aplicación haya incluido: ID de usuario, correo electrónico, roles, permisos, inquilino.

Firma — una comprobación criptográfica sobre las dos primeras partes, hecha con un secreto o una clave privada. Demuestra que el token no ha sido alterado desde su emisión.

Lo esencial que hay que entender: las dos primeras partes no están cifradas. Solo están codificadas, y cualquiera puede leerlas. Pegue un token en esta página y su contenido aparecerá al instante. Base64url es una forma de hacer que los datos puedan viajar en una URL o un encabezado, no una forma de ocultarlos.

Qué significa esto para lo que pone en un token

Dado que la carga útil es pública para cualquiera que tenga el token, la regla se sigue directamente: nunca ponga nada secreto en un JWT.

Lo que no debe ir en una carga útil: contraseñas, claves de API, datos de tarjetas de crédito, números de identidad nacional, información médica, cualquier cosa cubierta por la normativa de privacidad. Todo ello es legible por el usuario, por cualquier sistema que registre la petición y por cualquiera que obtenga el token.

Lo que sí debe ir: un ID de usuario, un rol, una caducidad, un emisor, una audiencia — identificadores y reclamaciones pensados para que los vea el sistema que los recibe.

La firma protege la integridad, no la confidencialidad. Garantiza que nadie ha cambiado el token. No hace nada por impedir que lo lean.

Decodificar no es verificar

Esta es la distinción que causa fallos de seguridad reales, así que conviene ser preciso.

Decodificar desempaqueta el Base64url y le muestra el JSON. No necesita ninguna clave, cualquiera puede hacerlo y no prueba absolutamente nada sobre si el token es auténtico.

Verificar vuelve a calcular la firma usando el secreto o la clave pública y comprueba que coincide. Solo esto le dice que el token fue realmente emitido por quien dice y que no ha sido manipulado.

Un token puede decodificarse perfectamente y ser una falsificación completa. Cualquiera puede fabricar un JWT que diga "role": "admin" y se mostrará estupendamente aquí — porque mostrarlo es todo lo que está ocurriendo.

Esta herramienta deliberadamente no verifica, y esa es la opción segura: la verificación requiere el secreto de firma, y pegar su secreto de firma en una página web sería mucho más peligroso que pegar un token. La verificación corresponde a su servidor, con su clave, usando una biblioteca adecuada.

La versión histórica de este error es el ataque alg: none. Las primeras bibliotecas JWT respetaban un encabezado que declaraba que no se había usado ningún algoritmo y aceptaban el token sin verificar. Un atacante podía editar la carga útil, poner alg en none y entrar sin más. Las bibliotecas modernas lo rechazan, pero por eso conviene fijar siempre el algoritmo esperado en lugar de confiar en que el encabezado se lo diga.

Leer las reclamaciones estándar

La mayoría de los nombres de campo cortos de una carga útil son reclamaciones registradas con significados fijos:

  • exp — hora de caducidad. A partir de ahí, el token debe rechazarse.
  • iat — issued at, emitido en. Cuándo se creó.
  • nbf — not before, no antes de. El token no es válido hasta esa hora.
  • sub — sujeto. Normalmente el ID de usuario.
  • iss — emisor. Quién creó el token.
  • aud — audiencia. A qué servicio está destinado.
  • jti — ID del token, usado en listas de revocación.

exp, iat y nbf son marcas de tiempo Unix — segundos desde el 1 de enero de 1970 — por eso parecen un número de diez dígitos sin sentido. Esta herramienta los convierte en fechas legibles, que suele ser la forma más rápida de responder a la pregunta que le trajo aquí: *¿ha caducado este token?*

Cómo usarla

  • Pegue su JWT (la cadena xxxxx.yyyyy.zzzzz)
  • Lea el encabezado y la carga útil decodificados más abajo
  • Copie cualquiera de las dos partes si la necesita

Conviene saber

  • Trate un token como una contraseña. Si todavía es válido, quien lo tenga puede actuar como ese usuario. No pegue tokens activos en herramientas que los suban, ni los publique en un ticket o un chat.
  • Los JWT son difíciles de revocar. Son válidos hasta que caducan, así que un token robado funciona hasta entonces salvo que mantenga una lista de bloqueo. Por eso importan las caducidades cortas.
  • Bearer no forma parte del token. Quite ese prefijo de un encabezado Authorization antes de decodificar.
  • Base64url no es Base64 estándar. Usa - y _ en lugar de + y / y normalmente elimina el relleno =, por lo que un bloque de JWT puede fallar en un decodificador Base64 corriente.
  • El desfase de reloj provoca fallos desconcertantes. Un token puede parecerle válido y ser rechazado por un servidor cuyo reloj difiera en un minuto o dos.
  • Un JWT no es una sesión. Lleva sus reclamaciones consigo, así que los cambios en el rol de un usuario no surten efecto hasta que el token caduca.

Preguntas frecuentes

¿Está cifrado un JWT?

No. El encabezado y la carga útil están codificados en Base64url, lo que permite ponerlos sin problemas en una URL o un encabezado HTTP pero no los oculta en absoluto. Cualquiera que tenga el token puede leer todas las reclamaciones que contiene, como demuestra esta página. La firma protege el token de ser modificado, no de ser leído.

¿Verifica esta herramienta la firma?

No, y deliberadamente. Verificar requiere el secreto de firma o la clave pública, y pegar su secreto de firma en una página web sería considerablemente más peligroso que pegar un token. La verificación corresponde a su servidor, usando una biblioteca adecuada. Esta herramienta decodifica y le muestra el contenido, que es lo que necesita al depurar.

¿Es seguro pegar aquí mi token?

Aquí sí — la decodificación ocurre íntegramente en su navegador y no se transmite nada, así que puede desconectarse de internet y seguirá funcionando. Aun así, tenga cuidado con las herramientas en general. Un JWT activo es una credencial que funciona, y un sitio que lo envía a un servidor acaba de recibir todo el acceso que otorga.

¿Cómo sé si mi token ha caducado?

Mire la reclamación exp, que es una marca de tiempo Unix en segundos. Esta herramienta la convierte en una fecha legible y le dice directamente si ese momento ya pasó. Si un token le parece válido pero un servidor lo rechaza, compruebe el desfase de reloj — una diferencia de uno o dos minutos entre máquinas basta.

¿Qué significan sub, iss, aud e iat?

Son reclamaciones registradas con significados estándar: sub es el sujeto, normalmente el ID de usuario; iss es el emisor que creó el token; aud es la audiencia prevista, es decir, qué servicio debe aceptarlo; iat es cuándo se emitió. Junto con exp y nbf cubren el quién, el dónde y el cuándo.

¿Por qué falla mi JWT en un decodificador Base64 normal?

Porque un JWT usa Base64url, una variante que sustituye + por - y / por _ y normalmente elimina el relleno =. Esas sustituciones existen para que el valor sea seguro dentro de una URL. Al devolver los caracteres originales, se decodifica en una herramienta Base64 estándar.

¿Puedo editar la carga útil de un JWT?

Puede cambiar el texto, pero el resultado será rechazado por cualquier servidor correctamente implementado, porque la firma ya no coincide con el contenido modificado. Para eso sirve exactamente la firma. Los tokens los reemite el servicio que los firma, no se editan a mano.

Herramientas relacionadas

Tutorial en vídeo

Añadimos herramientas nuevas con frecuencia — suscríbete en YouTube para enterarte de cada novedad.

Más herramientas

Ver todo

Aplicaciones recomendadas

Ver todo