Herramientas

Decodificador JWT Online Gratuito

Decodifica e inspecciona JSON Web Tokens directamente en tu navegador. Visualiza el header, el payload y los claims con fechas de expiración legibles. Nada se envía nunca a un servidor.

Inspector de Token

Algoritmo
Tipo
Expiración

Header

Payload

Firma

La verificación de la firma requiere la clave secreta y no es compatible con esta herramienta.
Toda la decodificación ocurre localmente en tu navegador. Tu token nunca se sube, almacena ni registra.

¿Qué es un JWT?

Un JSON Web Token (JWT, RFC 7519) es una forma compacta y segura para URL de representar claims entre dos partes. Está formado por tres partes codificadas en Base64URL unidas por puntos — header.payload.signature. Su uso más común es la autenticación sin estado de las API REST: tras iniciar sesión, el servidor emite un token firmado que el cliente envía en cada petición, de modo que el servidor puede verificar la identidad sin mantener el estado de la sesión.

Estructura del JWT: Header, Payload, Firma

Header

Declara el algoritmo de firma (alg, p. ej. HS256, RS256, ES256) y el tipo de token (typ), casi siempre JWT.

Payload

Contiene los claims estándar y personalizados. Solo está codificado en Base64URL, no cifrado — cualquiera puede leerlo, así que nunca guardes secretos aquí.

Firma

Se calcula firmando el header y el payload codificados con una clave secreta o privada. Demuestra la integridad pero no se puede verificar sin esa clave.

Claims JWT comunes explicados

El payload contiene claims — afirmaciones sobre el token. Estos claims registrados están definidos por el estándar JWT:

sub Subject — el sujeto al que se refiere el token, normalmente el ID de usuario.
iss Issuer — identifica quién emitió el token.
aud Audience — los destinatarios a los que va dirigido el token.
exp Expiration Time — marca de tiempo Unix después de la cual el token debe rechazarse.
iat Issued At — marca de tiempo Unix de cuándo se creó el token.
nbf Not Before — marca de tiempo Unix antes de la cual el token no debe aceptarse.
jti JWT ID — un identificador único, útil para evitar la reutilización del token.

Buenas prácticas de seguridad para JWT

Nunca pongas datos sensibles en el payload — solo está codificado, no cifrado, y cualquiera puede leerlo.
Establece siempre un claim exp y mantén cortas las duraciones de los tokens para limitar el impacto de un token filtrado.
Prefiere algoritmos asimétricos (RS256 o ES256) para microservicios, así los servicios pueden verificar sin compartir un secreto.
Valida siempre los claims iss y aud en el servidor y rechaza los tokens cuyo alg esté establecido en none.
Nunca expongas los tokens en URLs ni en archivos de log; envíalos en el header Authorization y guárdalos de forma segura.

Preguntas Frecuentes

No. Un JWT estándar está firmado, no cifrado. El header y el payload solo están codificados en Base64URL, lo que significa que cualquiera que tenga el token puede decodificar y leer su contenido. La firma solo garantiza que el token no ha sido manipulado — no oculta los datos. Si necesitas confidencialidad, usa JWE (JSON Web Encryption) o nunca coloques datos sensibles en el payload.

No. Verificar la firma de un JWT requiere la clave secreta (para HS256) o la clave pública (para RS256/ES256), que solo debería tener el servidor emisor. Esta herramienta decodifica intencionadamente el token en el lado del cliente sin verificación, de modo que ninguna clave abandone nunca tu dispositivo. Verifica siempre las firmas en tu servidor, nunca en el navegador.

HS256 es simétrico: la misma clave secreta firma y verifica el token, por lo que cualquier parte que pueda verificar también puede falsificar tokens. RS256 es asimétrico: una clave privada firma y una clave pública independiente verifica. RS256 es preferible para sistemas distribuidos y microservicios porque puedes compartir libremente la clave pública mientras mantienes secreta la clave privada de firma.

El claim exp es una marca de tiempo Unix en segundos. Un error común es proporcionarlo en milisegundos (13 dígitos) en lugar de segundos (10 dígitos), lo que sitúa la expiración muy en el pasado o el futuro. El desfase de reloj entre servidores también puede causar expiración prematura — concede un pequeño margen al validar. Usa el Inspector de Token de arriba para ver la fecha de expiración legible junto al valor en bruto.