Decodificar y verificar JWT (HS256 / HS384 / HS512)

Funciones

• ⚠️ Nunca uses un secreto de producción — usa uno de prueba (todo se ejecuta en local, pero pegar una clave de producción en una página es el mal hábito)
• Verifica firmas HS256 / HS384 / HS512 con tu secreto, con una comparación en tiempo constante que no retorna con un prefijo coincidente
• ⚠️ Un token con alg none es inválido en cuanto se da un secreto (la vulnerabilidad clásica de JWT)
• ⚠️ Una firma verificada solo significa que el contenido no se alteró — no que el token siga siendo válido; exp y nbf se informan, aud e iss son cosa tuya
• Sin secreto solo decodifica, y así lo dice la salida
• El secreto puede ser texto UTF-8 o Base64 (muchas claves se exportan en Base64)
• Divide y formatea la cabecera, el payload y la firma
• Convierte iat, nbf y exp a marcas de tiempo ISO e informa de caducidad y de «aún no válido»
• Acepta Base64URL sin relleno, el prefijo Bearer y tokens partidos en varias líneas
• Explica un número de segmentos incorrecto, y reporta un token de 5 partes como JWE cifrado y no como JWT
• Tamaño del token y si los servidores habituales lo rechazarían: nginx 8 KB por línea, Apache 8190, IIS 16384, Node 16 KB, Go 1 MB

Cómo se usa

1. Pega el token, con prefijo Bearer o sin él
2. Para verificar, escribe el secreto y elige texto UTF-8 o Base64; déjalo vacío para solo decodificar
3. Lee el veredicto de verificación, los tres segmentos y las marcas de tiempo
4. Pulsa Copiar para llevarte el resultado — una firma verificada sigue sin significar que el token sea válido

Preguntas frecuentes

¿Es seguro pegar mi secreto aquí?

⚠️ No uses un secreto de producción. Todo el cálculo ocurre en tu navegador y el secreto nunca se sube (sigue funcionando sin conexión una vez cargada). El problema no es la transmisión sino la costumbre: pegar una clave de producción en una página web, donde queda en el historial o el portapapeles, es algo que no deberías hacer. Usa un secreto de prueba dedicado para ver cómo se comporta la herramienta.

La firma se verificó, así que el token es válido, ¿no?

No. Una firma verificada solo significa que el contenido firmado con ese secreto no se alteró. Que el token siga sirviendo depende además de exp (¿caducado?), nbf (¿ya vigente?), aud e iss (¿para quién, de quién?) — la herramienta informa de exp y de nbf, mientras que aud e iss son cosa tuya. Además, esta herramienta solo verifica HS256 / HS384 / HS512 simétricos; RS256 y ES256 necesitan clave pública y quedan fuera de su alcance.

¿Qué pasa si el alg es none?

Se trata como inválido cuando se da un secreto. Es la vulnerabilidad clásica de JWT: el atacante pone alg en none y quita la firma, y una implementación ingenua que se salta la verificación para none acepta cualquier token falsificado. Esta herramienta trata «secreto dado + alg none» como fallo de verificación, no como un salto.

¿El secreto va como texto o en Base64?

Un secreto HMAC es una secuencia de bytes, y los bytes tienen más de una escritura. Valores al estilo jwt.io como `your-256-bit-secret` se usan como texto UTF-8, así que elige texto UTF-8. Si tu clave es una cadena Base64 que te dieron (una clave binaria exportada de un archivo de configuración o un gestor), elige Base64 y la herramienta la decodifica a bytes antes de verificar — las dos opciones producen firmas totalmente distintas, y la equivocada falla.

¿El payload está cifrado?

No. Base64URL es una codificación, no un cifrado, así que quien tenga el token puede leer todo lo que lleva dentro — que es justo lo que hace esta herramienta. Nunca pongas contraseñas, teléfonos ni números de identidad en un payload JWT. Si necesitas confidencialidad, usa JWE, que produce un token de 5 partes que esta herramienta no sabe leer.

¿Qué reloj decide si ha caducado?

El tuyo. El indicador de caducidad compara exp con la hora de tu equipo, así que un reloj mal puesto da una respuesta equivocada. La comprobación de caducidad que manda pertenece siempre al servidor, porque el reloj del cliente se puede poner en cualquier cosa.