Cómo leer un JWT, y por qué decodificar no es verificar

Las tres partes

Un JWT es una cadena de tres partes codificadas en base64url y separadas por puntos: cabecera.carga.firma. El RFC 7519 lo describe como una secuencia de partes seguras para URL separadas por puntos, cada una con un valor codificado en base64url. Este es un ejemplo inventado, firmado con una clave de usar y tirar (no da acceso a nada):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFuYSIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDAzNjAwfQ.gXp1Px7z_ClrGj78UjJKhSZ71IuYJpyz5YWbOqOSVQo

• Cabecera (eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9): se decodifica como {"alg":"HS256","typ":"JWT"}, que indica que el token está firmado con HMAC SHA-256.
• Carga útil (la parte central): se decodifica como {"sub":"1234567890","name":"Ana","iat":1700000000,"exp":1700003600}. Son las «declaraciones» (claims).
• Firma (la última parte): un valor criptográfico calculado sobre las dos primeras con una clave secreta o privada. Son datos binarios, así que al decodificarla no sale nada legible.

Cómo decodificar uno en un minuto

Pega el token en el decodificador de JWT. Separa el token, decodifica la cabecera y la carga y las muestra como JSON formateado, y lo hace en tu navegador: un token suele llevar la identidad de un usuario, así que es mejor no pegar uno real en una web que lo envíe a un servidor. Si prefieres hacerlo a mano, toma la primera y la segunda parte y pasa cada una por una decodificación base64url (cambia - por + y _ por /, añade = hasta que la longitud sea múltiplo de 4 y decodifica como base64); la herramienta de Base64 hace ese paso.

Las declaraciones que verás más

El RFC 7519 registra unos cuantos nombres estándar. Los que te encontrarás una y otra vez:

Las declaraciones de tiempo (exp, nbf, iat) son un NumericDate: el número de segundos desde 1970-01-01T00:00:00Z UTC, ignorando los segundos intercalares, el mismo tiempo Unix que define POSIX. En el ejemplo, iat es 1700000000 (14 de noviembre de 2023, 22:13:20 UTC) y exp es 1700003600, exactamente una hora después. El conversor de timestamp convierte esos números en fechas; si mezclas segundos y milisegundos, mira la guía sobre el timestamp Unix. El RFC 7519 dice también que exp se comprueba comparándolo con la hora actual y que se puede admitir un pequeño margen, normalmente no más de unos minutos, por desfase entre relojes.

Decodificar no es verificar

Este es el error que causa vulnerabilidades reales. Cualquiera que tenga el token puede leer lo que hay en la carga, porque base64url es una codificación, no un cifrado, y cualquiera puede también escribir una carga que diga lo que quiera. Lo que impide la falsificación es la firma, y la firma solo sirve si el servidor la comprueba de verdad.

Verificar significa recalcular la firma con la clave correcta y compararla, y después comprobar las declaraciones: que exp no haya pasado, que aud seas tú, que iss sea quien esperas. Una herramienta que decodifica un token (incluida la nuestra) te dice lo que el token afirma; no te dice si es auténtico. No tomes decisiones de acceso con una carga que solo has decodificado.

El RFC 8725, el documento de mejores prácticas para JWT, recoge qué sale mal cuando se omite. Describe cómo un atacante puede cambiar el algoritmo a none y algunas bibliotecas «validaban» el token sin comprobar ninguna firma, y cómo un token RS256 puede cambiarse a HS256 para que una biblioteca use la clave pública RSA como secreto HMAC. Entre sus medidas están dejar que quien llama elija los algoritmos admitidos, no aceptar ningún otro y usar cada clave con exactamente un algoritmo. Advierte también de que las aplicaciones no deben fiarse de las declaraciones recibidas sin validarlas, incluidos el emisor, el sujeto y la audiencia.

No pongas secretos en la carga

Como la carga de un token firmado es legible, no guardes en ella contraseñas, números de tarjeta ni otros secretos. El RFC 7519 dice que un JWT puede contener información sensible para la privacidad y que hay que tomar medidas para evitar que se revele: usar un JWT cifrado, o asegurarse de que los tokens con información sensible sin cifrar solo viajen por TLS, y, lo más simple, no incluir esa información. Recuerda también que un token acaba con facilidad en registros, en el almacenamiento del navegador y en URL.

Comprobaciones prácticas cuando un token «no funciona»

1. ¿Caducado? Convierte exp a fecha y compárala con ahora. El desfase de reloj entre servidores es un sospechoso habitual.
2. ¿Audiencia o emisor equivocados? Compara aud e iss con lo que espera tu servicio.
3. ¿Algoritmo o clave equivocados? Mira alg en la cabecera frente a lo que acepta el verificador.
4. ¿Cortado o estropeado? Un token firmado tiene exactamente dos puntos. Un salto de línea o un espacio al copiar y pegar rompe la firma.

Fuentes y más información

• RFC 7519: JSON Web Token (JWT)
• RFC 8725: JSON Web Token Best Current Practices

Datos comprobados el 3 de octubre de 2026.