🔑 Decodificador JWT ☆

Resumen

Decodificador JWT decodifica cualquier JSON Web Token directamente en tu navegador. Pega un token y ve al instante sus tres partes: la cabecera (algoritmo, tipo, key ID), el payload (todos los claims como JSON formateado) y la firma en bruto. Los claims de tiempo se traducen a fechas legibles, y la herramienta indica si el token es válido, está caducado, aún no es válido o no tiene caducidad. Todo funciona en el cliente, tu token nunca se sube, algo importante porque los JWT suelen llevar identificadores de sesión y datos personales. Decodificar no verifica la firma.

Qué contiene un JWT

Un JWT son tres segmentos base64url separados por puntos. La cabecera indica el algoritmo de firma y el id de clave; el payload lleva claims como iss (emisor), sub (sujeto), aud (audiencia), exp (caducidad), iat (emitido en) y nbf (no antes de); la firma permite a un servidor verificar que el token lo emitió una parte de confianza y no fue alterado. El decodificador muestra las tres partes, formatea el JSON, humaniza los claims de tiempo e indica si el token es válido, está caducado o aún no está activo.

Especificaciones y compatibilidad

Propiedad	Comportamiento
Entrada	Cualquier token JWS (header.payload.signature)
Partes decodificadas	Cabecera, claims del payload y firma en bruto
Claims de tiempo	exp, iat y nbf como fechas legibles con estado
Estado de validación	Válido, caducado, aún no válido o sin caducidad
Firma	No se verifica: solo decodificación
Procesamiento	100% en el cliente; los tokens nunca se suben
Coste	Gratis, sin cuenta y tokens ilimitados

Privacidad: los tokens de sesión se quedan en el navegador

Un JWT suele ser una credencial viva: pegarlo en un decodificador en servidor entregaría una sesión válida. Aquí todo se decodifica localmente: nada se transmite, almacena ni registra, y la página funciona sin conexión. Trata también la salida como sensible, porque los payloads suelen contener correos e identificadores.

Depurar JWT con seguridad

• Comprueba exp primero: la mayoría de errores de «token inválido» son simple caducidad.
• Compara iat y nbf cuando los relojes entre servicios se desajustan.
• Verifica que aud e iss coinciden con lo que espera la API.
• Recuerda que alg: none o los algoritmos simétricos exigen validación cuidadosa en el servidor.
• Nunca pegues tokens de producción en herramientas que no controles.

Relacionado: explora las herramientas de desarrollo para Base64, hash y pruebas de regex.

Estructura JWT, firmas y errores comunes

Un JSON Web Token tiene tres partes separadas por puntos: una cabecera que describe el algoritmo, un payload con las claims y una firma que permite al receptor verificar que las dos primeras no se alteraron. Las tres están codificadas en Base64URL, que es codificación, no cifrado: cualquiera que tenga el token puede leer las claims, así que nada sensible debe ir en el payload. Decodificar es por tanto siempre seguro en local, mientras que verificar requiere el secreto o la clave pública y debe ocurrir en el servidor. Varios errores se repiten en sistemas reales. El ataque alg:none aprovecha bibliotecas que confiaban en la cabecera y aceptaban un token sin firma; una implementación correcta fija el algoritmo esperado y rechaza lo demás. Usar HS256, un algoritmo simétrico, con un secreto débil o filtrado es otro: el secreto debe ser largo y aleatorio, y los algoritmos asimétricos como RS256 son preferibles cuando muchos deben verificar pero solo uno puede firmar. La validación de claims se olvida con facilidad: exp y nbf deben comprobarse contra la hora actual, iss y aud deben coincidir con los valores esperados, y jti permite revocar cuando roban un token. Los tokens son credenciales de portador, así que deben viajar solo por HTTPS y guardarse donde los scripts no puedan leerlos si el XSS es una preocupación. Recuerda que un token decodificado no prueba nada hasta que se verifica la firma. Esta herramienta decodifica en local y no almacena nada.