Decodificador y Verificador de JWT

Qué hace esta herramienta

Pega un JSON Web Token y verás sus tres partes por separado: la cabecera, el contenido y la firma. Los campos de tiempo se traducen a fechas legibles y se te dice si el token sigue vigente o ya caducó.

Todo ocurre en tu navegador: el token no se envía a ningún servidor ni se guarda en ningún registro.

Cómo está hecho un JWT

Un token es una cadena con tres partes separadas por puntos:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJleHAiOjE3NzEyMDAwMDB9.dBjftJeZ4CVP…
└──────── cabecera ────────┘ └──────────── contenido ───────────┘ └─── firma ───┘

• Cabecera — con qué algoritmo se firmó y qué tipo de token es.
• Contenido (payload) — los datos: quién es el usuario, quién emitió el token, cuándo caduca.
• Firma — lo que permite comprobar que nadie ha tocado las dos partes anteriores.

Las dos primeras son simplemente Base64 URL-safe. No hay cifrado por ningún lado.

Lo más importante: el contenido no es secreto

Si esta página te enseña el contenido de tu token sin pedirte ninguna clave, es porque cualquiera puede hacerlo. Y esa es exactamente la propiedad que hay que interiorizar:

Un JWT no oculta su contenido. Lo protege de ser modificado. Son dos cosas distintas.

La firma garantiza integridad y autenticidad: si alguien cambia un carácter del contenido, la firma deja de cuadrar y el servidor rechaza el token. Pero leerlo no requiere nada.

Las consecuencias son directas:

• Nunca metas en el contenido contraseñas, números de tarjeta, datos personales sensibles, claves internas ni nada que no quieras que vea el propio usuario que lleva el token.
• Un JWT es una credencial: quien lo tenga puede usarlo hasta que caduque. Trátalo como una contraseña — no lo pegues en sitios cualquiera, no lo dejes en registros, no lo guardes en localStorage si puedes evitarlo.
• Por eso, aunque aquí no salga de tu navegador, la costumbre sana es depurar con tokens de prueba o ya expirados, no con uno de producción vigente.

Los campos que importan

Algunos nombres están definidos por el estándar (RFC 7519) y significan lo mismo en cualquier sistema:

Todo lo demás son campos propios de cada sistema: role, email, permissions, lo que haya decidido quien lo emite.

Los tres campos de tiempo son timestamps Unix

exp, iat y nbf van en segundos desde 1970, no en milisegundos. Esta herramienta los convierte a fechas legibles automáticamente.

El error clásico aparece al generar tokens desde JavaScript, donde Date.now() devuelve milisegundos:

// MAL: caduca en el año 58000
exp: Date.now() + 3600000

// BIEN
exp: Math.floor(Date.now() / 1000) + 3600

Si al decodificar ves una expiración en 1970 o en un año imposible, es esto. Puedes comprobar cualquier valor suelto en el conversor de timestamp.

Por qué esta herramienta no verifica la firma

Es una decisión deliberada y conviene explicarla, porque hay páginas que sí lo ofrecen.

Verificar la firma requiere el secreto (en HS256) o la clave pública (en RS256). El secreto de firma es el material más sensible de un sistema de autenticación: quien lo tenga puede fabricar tokens válidos para cualquier usuario, incluido un administrador.

Una página que te pide pegar tu secreto para “validar” el token te está pidiendo la llave de tu sistema. No importa lo que prometa sobre no guardarlo.

Lo que sí se puede hacer sin claves, y es lo que se hace aquí:

• Leer la cabecera y el contenido completos.
• Comprobar que la estructura es correcta.
• Traducir las fechas y decir si el token está vigente o expirado.
• Avisar del algoritmo declarado.

La verificación de firma es trabajo del servidor, con su librería y su secreto, y ahí es donde debe quedarse.

Dos cosas que sí se pueden detectar leyendo

El algoritmo none

El estándar permite alg: none, que significa “este token no lleva firma”. Existía para casos donde la integridad se garantiza por otra vía, pero se convirtió en una de las vulnerabilidades más conocidas del formato:

1. El atacante coge un token válido.
2. Cambia la cabecera a alg: none.
3. Modifica el contenido a su gusto — por ejemplo, "role": "admin".
4. Borra la firma.
5. Una librería mal configurada, que “confía” en el algoritmo que dice la cabecera, lo acepta.

Si ves alg: none en un token real, es una alarma. La defensa es siempre la misma: fijar en el servidor el algoritmo esperado en lugar de leerlo del token.

La confusión de algoritmo RS256 → HS256

La variante fina del mismo problema: un token firmado con RS256 usa una clave privada para firmar y la pública para verificar. Si un atacante cambia la cabecera a HS256 —que es simétrico—, una librería ingenua intentará verificar usando como secreto… la clave pública, que es de dominio público. Y el token falso pasa.

La defensa, otra vez, es no dejar que el token elija el algoritmo. Las dos están recogidas en la RFC 8725, el documento de buenas prácticas de JWT.

Cuándo se usa esto a diario

• Ver por qué una API devuelve 401: casi siempre el token expiró, y la fecha se lee aquí.
• Comprobar qué permisos lleva un usuario que dice no poder entrar a algo.
• Verificar que tu backend está metiendo los campos que crees que mete.
• Entender el token de un proveedor externo (Auth0, Firebase, Cognito) antes de integrarlo.

Para inspeccionar solo una de las partes por tu cuenta, o para tokens con formato raro, el convertidor de Base64 con la opción URL-safe hace la decodificación cruda.