Cómo decodificar y verificar tokens JWT en tu navegador

Si has trabajado con cualquier sistema de autenticación web moderno — OAuth 2.0, OpenID Connect o una API personalizada — casi seguro que te has topado con tokens JWT. Aparecen en las cabeceras Authorization, en las cookies, en el almacenamiento local y en las sesiones de depuración a las 2 de la madrugada cuando un flujo de inicio de sesión falla misteriosamente. Entender qué contiene realmente un JWT, cómo leerlo y cómo detectar problemas comunes hace que la depuración de la autenticación sea drásticamente más rápida.

El Decodificador JWT de BrowseryTools te permite pegar cualquier token JWT y ver al instante su cabecera, su carga útil y su estado de expiración decodificados — todo en tu navegador, sin que el token salga jamás de tu dispositivo.

¿Qué es un JWT?

JWT significa JSON Web Token, definido en el RFC 7519. Un JWT es un token compacto y seguro para URL que codifica un conjunto de reclamaciones (claims) — afirmaciones sobre un sujeto, normalmente un usuario — en un formato que se puede verificar y en el que se puede confiar. La propiedad clave de un JWT es que es autocontenido: el propio token lleva toda la información que un servidor necesita para autenticar una petición, sin una consulta a la base de datos.

Un JWT tiene este aspecto:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfODQyMTkiLCJuYW1lIjoiSmFuZSBEb2UiLCJlbWFpbCI6ImphbmUuZG9lQGV4YW1wbGUuY29tIiwicm9sZXMiOlsidXNlciIsImVkaXRvciJdLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsImlhdCI6MTczODM2ODAwMCwiZXhwIjoxNzM4MzcxNjAwLCJqdGkiOiI3ZjNhOWI0Yy0xZDJlLTQ1NmYtYWJjZC04OTAxMjM0NTY3ODkifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

A primera vista parece un galimatías. Pero tiene una estructura muy precisa: tres secciones codificadas en Base64URL separadas por puntos. Cada sección tiene un propósito específico.

La estructura de tres partes: Cabecera.CargaÚtil.Firma

Parte 1: la cabecera

El primer segmento, antes del primer punto, es la cabecera. Es un objeto JSON codificado en Base64URL que describe el tipo del token y el algoritmo de firma. Decodificada, la cabecera del ejemplo de arriba tiene este aspecto:

{
  "alg": "HS256",
  "typ": "JWT"
}

El campo alg especifica el algoritmo de firma. Los valores comunes con los que te encontrarás son:

• HS256 — HMAC con SHA-256. Usa una clave secreta compartida. Tanto el emisor como el verificador deben tener el mismo secreto. Común en aplicaciones monolíticas.
• RS256 — firma RSA con SHA-256. Usa un par de claves pública/privada. El emisor firma con la clave privada; los verificadores comprueban con la clave pública. Común en sistemas distribuidos y proveedores OAuth.
• ES256 — ECDSA con P-256 y SHA-256. Como RS256 pero usando curvas elípticas — claves más cortas, mismo nivel de seguridad. Preferido en sistemas modernos de alto rendimiento.
• none — sin firma. Nunca aceptes esto en producción. Surge una notoria vulnerabilidad de seguridad cuando los servidores aceptan tokens sin firmar porque el cliente cambió alg a "none".

Parte 2: la carga útil

El segundo segmento es la carga útil (payload) — los datos reales que lleva el token. También es un objeto JSON codificado en Base64URL. La carga útil decodificada de nuestro ejemplo:

{
  "sub": "usr_84219",
  "name": "Jane Doe",
  "email": "jane.doe@example.com",
  "roles": ["user", "editor"],
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "iat": 1738368000,
  "exp": 1738371600,
  "jti": "7f3a9b4c-1d2e-456f-abcd-890123456789"
}

La carga útil contiene dos tipos de reclamaciones: las reclamaciones registradas definidas por la especificación JWT, y las reclamaciones privadas/personalizadas añadidas por tu aplicación (comoname, email y roles arriba).

Parte 3: la firma

El tercer segmento es la firma. Se calcula tomando la cabecera codificada en Base64URL, un punto, la carga útil codificada en Base64URL, y firmando el resultado con el algoritmo y la clave especificados en la cabecera. Para HS256:

HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

La firma garantiza la integridad: si alguien modifica aunque sea un solo carácter en la cabecera o la carga útil después de que el token se emita, la firma se vuelve inválida y la verificación falla. Sin conocer el secreto de firma (o la clave privada del emisor para RS256/ES256), un atacante no puede falsificar un token válido.

Referencia de reclamaciones JWT estándar

Por qué la reclamación exp es crucial

La reclamación exp es una marca de tiempo Unix — el número de segundos desde el 1 de enero de 1970 (UTC). En nuestro ejemplo, "exp": 1738371600. Para convertir esto a una fecha legible para humanos, puedes usar JavaScript:

new Date(1738371600 * 1000).toUTCString()
// → "Sat, 01 Feb 2026 01:00:00 GMT"

La expiración del JWT es lo primero que hay que comprobar cuando un token está siendo rechazado. Un token que era válido ayer fallará hoy si su exp está en el pasado — esto es por diseño. Los tokens de corta duración (de 15 minutos a 1 hora) limitan la ventana de daño si un token es robado. Los tokens de mayor duración (días o semanas) son más cómodos pero más peligrosos si quedan comprometidos.

El Decodificador JWT de BrowseryTools lee automáticamente las reclamaciones exp e iat y las muestra como fechas legibles para humanos junto a las marcas de tiempo Unix en bruto, así que nunca tienes que hacer los cálculos mentales a mano.

Escenarios comunes de depuración de JWT

Token expirado (401 Unauthorized)

El error de JWT más común. El servidor rechazó el token porque la hora actual ha superado el valor deexp. Solución: implementa un flujo de actualización de token usando un token de actualización de mayor duración, o simplemente vuelve a autenticarte. Pega el token en el decodificador para confirmar exactamente cuándo expiró.

Audiencia incorrecta

Si tu API valida la reclamación aud y el token se emitió para una audiencia diferente (por ejemplo, un token emitido para https://api-staging.example.com enviado a https://api.example.com), el servidor lo rechazará. Decodifica el token e inspecciona el campoaud para confirmar que coincide con lo que espera el servicio receptor.

Discrepancia de algoritmo

Si tu servidor espera RS256 pero recibe un token firmado con HS256 (o viceversa), la validación falla. Esto puede ocurrir durante la rotación de claves o al cambiar de proveedor de autenticación. Comprueba el campo alg en la cabecera decodificada frente a lo que tu servidor está configurado para aceptar.

Firma inválida

Si la carga útil ha sido manipulada — aunque solo se haya cambiado un carácter — la firma no coincidirá. Esto también ocurre si estás usando el secreto incorrecto o la clave pública incorrecta para verificar. Decodificar la cabecera y la carga útil (lo que no requiere ningún secreto) te permite al menos inspeccionar qué afirma el token, aunque no puedas verificar su autenticidad en el lado del cliente.

JWT frente a tokens de sesión: cuándo usar cada uno

Los JWT y los tokens de sesión tradicionales resuelven el mismo problema — identificar a un usuario autenticado a lo largo de varias peticiones — pero lo hacen de forma diferente, y ninguno es universalmente mejor.

Los tokens de sesión tradicionales son cadenas aleatorias opacas (por ejemplo, un UUID) almacenadas en el lado del servidor en un almacén de sesiones (Redis, base de datos). En cada petición, el servidor busca el token en el almacén y recupera los datos del usuario. El servidor tiene control total: invalidar una sesión revoca el acceso de inmediato.

Los JWT no tienen estado. El servidor emite un token firmado y no guarda ningún registro de él. En cada petición, el servidor verifica la firma y confía en las reclamaciones sin ninguna consulta a la base de datos. Esto escala horizontalmente sin estado compartido — cualquier servidor con la clave de verificación puede autenticar la petición. La contrapartida: no puedes revocar un JWT de inmediato antes de que expire (a menos que implementes una lista de bloqueo de tokens, lo que reintroduce el estado).

• Usa los JWT para microservicios sin estado, sistemas distribuidos, APIs móviles y autenticación entre dominios (flujos OAuth/OIDC). Mantén cortos los tiempos de expiración.
• Usa los tokens de sesión cuando necesites capacidad de revocación inmediata (cierre de sesión, suspensión de cuenta, incidentes de seguridad), o cuando todos tus servicios compartan un almacén de sesiones rápido.

Cómo usar el Decodificador JWT de BrowseryTools

Abre el Decodificador JWT y pega tu token en el campo de entrada. La herramienta divide inmediatamente el token por los dos puntos y muestra:

• Panel de la cabecera: el JSON decodificado que muestra alg, typ y cualquier otro campo de la cabecera. Útil para identificar el algoritmo de firma de un vistazo.
• Panel de la carga útil: el JSON decodificado completo con todas las reclamaciones. Las marcas de tiempo se muestran tanto en formato Unix en bruto como en fechas UTC legibles para humanos, para que puedas ver de inmediato la expiración sin conversión mental.
• Estado de expiración: un indicador claro que muestra si el token es actualmente válido, ya ha expirado o aún no está activo (basándose en nbf). Si ha expirado, ves exactamente hace cuánto expiró.
• Segmento de la firma: la firma en bruto codificada en Base64URL, mostrada como referencia. La herramienta no verifica la firma (eso requiere el secreto o la clave pública), pero decodifica y muestra toda la información que necesitas para depurar.

No hay envío de formulario, ni petición al servidor, ni acceso al portapapeles más allá de lo que pegas explícitamente. El análisis del token ocurre por completo en JavaScript que se ejecuta en la pestaña de tu navegador.

Decodifica tu token JWT ahora

Tanto si estás depurando un token expirado, inspeccionando reclamaciones de un proveedor OAuth, comprobando qué roles se le han concedido a un usuario o simplemente intentando entender qué está emitiendo realmente tu sistema de autenticación — el Decodificador JWT de BrowseryTools te da las respuestas al instante. Sin registro, sin extensiones que instalar, sin que ningún dato se envíe a ningún sitio.