Decodificar JWT Online
Decodifica tokens JWT en tu navegador, sin enviar datos a ningún servidor.
Por qué usarlo
Depura tokens JWT al instante
100% privado
La decodificación ocurre en tu navegador. Tu token nunca sale de tu dispositivo.
Instantáneo
Decodificación en tiempo real mientras escribes. Sin esperas ni botones.
JSON formateado
Header y payload mostrados como JSON legible con colores y sangría correcta.
Compatible con todos los JWT
Funciona con HS256, RS256, ES256 y cualquier algoritmo del estándar JOSE.
Cómo funciona
Tres pasos, sin complicaciones
Pega tu token JWT
Copia y pega cualquier token JWT en el campo de entrada. El formato es tres partes separadas por puntos: header.payload.signature.
Decodificación instantánea
El header y el payload se decodifican de Base64URL y se muestran como JSON formateado. Verás el tipo de algoritmo, emisor, expiración y todas las claims.
Analiza los datos
Revisa cada campo del payload: iss (emisor), sub (sujeto), exp (expiración), iat (emitido en), aud (audiencia) y cualquier claim personalizado.
Preguntas frecuentes
¿Tienes dudas?
JWT (JSON Web Token) es un estándar abierto (RFC 7519) que define una forma compacta y autocontenida de transmitir información entre partes como un objeto JSON. El token está firmado digitalmente, lo que permite verificar su autenticidad. Se usa ampliamente para autenticación y autorización en APIs REST y aplicaciones web modernas.
Cuando el usuario inicia sesión, el servidor crea un JWT firmado con una clave secreta (HS256) o clave privada (RS256) y lo envía al cliente. El cliente almacena el token (generalmente en memoria o localStorage) y lo incluye en cada petición como 'Authorization: Bearer <token>'. El servidor verifica la firma del token sin necesidad de consultar una base de datos, lo que hace que JWT sea un mecanismo de autenticación sin estado (stateless).
Un JWT está firmado, no cifrado. Esto significa que cualquier persona puede decodificar el payload y leer su contenido — por eso nunca debes incluir contraseñas, tarjetas de crédito ni datos sensibles en el payload. La firma garantiza integridad (nadie puede modificar el token sin invalidarlo), pero no confidencialidad. Si necesitas cifrar el contenido, usa JWE (JSON Web Encryption).
Las claims son declaraciones sobre el sujeto del token. Las claims registradas (RFC 7519) incluyen: iss (issuer, quien emitió el token), sub (subject, sobre quién es el token), exp (expiration, cuándo expira en Unix timestamp), iat (issued at, cuándo fue emitido), aud (audience, para quién es válido), nbf (not before, desde cuándo es válido) y jti (JWT ID, identificador único). Además de estas, puedes incluir cualquier claim personalizada.
No sin invalidarlo. Si modificas cualquier parte del header o payload y no tienes la clave secreta para re-firmar, la firma resultante será incorrecta y el servidor rechazará el token. Esta propiedad es fundamental para la seguridad de JWT. Sin embargo, existen vulnerabilidades conocidas: el ataque 'alg:none' (donde el header declara algoritmo none para evitar verificación) y la confusión RS256/HS256. Siempre verifica que tu librería JWT maneje estos casos.
Las cookies de sesión almacenan un ID en el servidor (stateful), mientras que JWT contiene toda la información en el token (stateless). JWT escala mejor en arquitecturas distribuidas y microservicios porque no requiere sesiones compartidas. Sin embargo, JWT tiene desventajas: no puedes revocar un token antes de su expiración sin infraestructura adicional (blacklist), y si el token es robado, es válido hasta que expire. Para la mayoría de aplicaciones web tradicionales, las cookies httpOnly con sesiones en servidor siguen siendo la opción más segura.
JWT: historia, estructura técnica y seguridad en profundidad
JSON Web Token fue estandarizado por la IETF en mayo de 2015 como RFC 7519, parte del framework JOSE (JSON Object Signing and Encryption). JOSE incluye también JWS (JSON Web Signature, RFC 7515), JWE (JSON Web Encryption, RFC 7516), JWK (JSON Web Key, RFC 7517) y JWA (JSON Web Algorithms, RFC 7518). El trabajo en este estándar comenzó en 2011, liderado por Mike Jones (Microsoft), John Bradley y Nat Sakimura. Antes de JWT, los desarrolladores usaban SAML (Security Assertion Markup Language), un estándar basado en XML considerablemente más verboso y complejo.
La estructura de un JWT consiste en tres partes codificadas en Base64URL separadas por puntos. Base64URL difiere de Base64 estándar en que reemplaza '+' por '-' y '/' por '_', y omite el padding '=', haciéndolo seguro para usar en URLs y headers HTTP sin codificación adicional. El header especifica el tipo de token ('typ': 'JWT') y el algoritmo de firma ('alg'). Los algoritmos más comunes son HS256 (HMAC-SHA256, clave simétrica), RS256 (RSA-SHA256, clave asimétrica), ES256 (ECDSA-SHA256, curva elíptica P-256) y el peligroso 'none' (sin firma, que nunca debe aceptarse en producción).
Las vulnerabilidades más críticas de JWT están bien documentadas en el Top 10 de OWASP API Security. La vulnerabilidad 'alg:none' (CVE-2015-9235 en varias librerías) permite a un atacante modificar el header para declarar que no se necesita firma, con lo que el servidor acepta cualquier payload arbitrario si la librería no valida explícitamente el algoritmo. La confusión de algoritmos RS256/HS256 ocurre cuando un servidor configurado para RS256 acepta también HS256: el atacante puede usar la clave pública RSA (que es, por definición, pública) como clave HMAC secreta para firmar tokens fraudulentos. Librerías modernas como jose, python-jose y jsonwebtoken resuelven estos problemas requiriendo que el algoritmo se especifique explícitamente al verificar.