Decodificador JWT

Qué hace en realidad un decodificador de JWT

Un JSON Web Token (JWT) parece una cadena larga y opaca de caracteres aleatorios, pero no está cifrado ni es un cifrado secreto. Es un contenedor compacto y seguro para URL que transporta datos estructurados entre dos partes. Pega un token en el decodificador de arriba y este separa esa cadena y te muestra el JSON real que hay dentro — los metadatos, las reclamaciones (claims), para quién es el token y cuándo caduca. Todo ocurre directamente en tu navegador. El token nunca se sube, ni se registra, ni se envía a ningún sitio, algo que importa mucho cuando lo que estás inspeccionando es una credencial de sesión activa.

Tres partes, dos puntos

Todo JWT bien formado consta de tres cadenas codificadas en Base64url unidas por puntos: header.payload.signature (cabecera.carga.firma). Ese único carácter de punto es como los analizadores saben dónde termina una sección y empieza la siguiente, y es la razón por la que un token con un número incorrecto de puntos se rechaza antes incluso de leer nada más.

La cabecera (header) es un pequeño objeto JSON que describe el propio token. Casi siempre contiene typ (el tipo, normalmente JWT) y alg — el algoritmo de firma, como HS256 (HMAC con SHA-256) o RS256 (RSA con SHA-256). La cabecera le indica a un verificador exactamente cómo se produjo la firma.

La carga útil (payload) es la parte que más le interesa a la mayoría. Es otro objeto JSON que contiene las reclamaciones (claims) — afirmaciones sobre el usuario y el token. La especificación clasifica las reclamaciones en registradas (nombres estándar y reservados), públicas y privadas (nombres personalizados que tú inventas para tu propia aplicación). Decodificar la carga útil es lo que revela quién ha iniciado sesión, qué rol tiene y cuándo expira su sesión.

La firma (signature) es el sello criptográfico. Se calcula sobre la cabecera y la carga útil codificadas, usando el algoritmo de la cabecera más una clave secreta o privada. Como cubre las otras dos secciones, cualquier cambio en la cabecera o en la carga útil — aunque sea un solo carácter — la invalida.

Las reclamaciones que verás con más frecuencia

Las reclamaciones registradas son nombres cortos de tres letras definidos por la RFC 7519 para que distintos sistemas puedan interoperar. Unas cuantas aparecen casi en todas partes:

• iss — issuer (emisor): quién acuñó el token (tu servidor de autenticación o proveedor de identidad).
• sub — subject (sujeto): la entidad a la que se refiere el token, normalmente un ID de usuario estable.
• aud — audience (audiencia): el destinatario al que va dirigido el token. Una API debería rechazar tokens cuya audiencia no sea ella misma.
• exp — expiration time (hora de expiración): una marca de tiempo Unix tras la cual el token no debe aceptarse.
• iat — issued at (emitido en): la marca de tiempo Unix en que se creó el token.

También puedes encontrarte con nbf (not before, no antes de) y jti (un ID de token único). Las marcas de tiempo son segundos desde 1970 en UTC, y por eso un decodificador que las muestra como fechas legibles te ahorra el cálculo mental de comprobar si un token ya ha caducado.

Decodificar no es verificar — aquí es donde mucha gente tropieza

Esta distinción es lo más importante que hay que entender sobre los JWT. Decodificar significa leer el contenido: no requiere ninguna clave y cualquiera que tenga el token puede hacerlo, porque Base64url es una codificación, no un cifrado. Verificar significa demostrar que el token es auténtico y no ha sido manipulado — recalcular la firma con la clave secreta o pública correcta y confirmar que coincide.

Esta herramienta decodifica. Te muestra lo que el token dice, no si el token es fiable. Un token podría estar falsificado, caducado o reenviado y aun así decodificarse en un JSON de aspecto perfectamente limpio. Nunca tomes una decisión de autorización basándote únicamente en reclamaciones decodificadas. En producción, verificas la firma en el servidor, compruebas exp y confirmas que iss y aud coinciden con lo que esperas — usando una biblioteca contrastada, nunca una comparación de cadenas hecha a mano.

Una carga útil no es una caja fuerte

Como la carga útil solo está codificada en Base64url, cualquiera que intercepte el token puede leerla. Trata todo lo que contiene como público. No coloques contraseñas, números completos de tarjeta de crédito, claves secretas ni ningún dato personal sensible en las reclamaciones de un JWT — si puedes decodificarlo aquí con un clic, también podrá hacerlo cualquier otra persona que consiga una copia. La firma protege contra la modificación, nunca contra la lectura. Si realmente necesitas ocultar el contenido de la carga útil, ese es el trabajo de JWE (tokens cifrados), una especificación completamente distinta.

Privacidad y herramientas relacionadas

Inspeccionar un token es un acto delicado, por eso este decodificador se ejecuta por completo en el lado del cliente — el análisis es JavaScript puro dentro de tu pestaña y nada sale de tu máquina. Pegar un token de sesión en una herramienta que depende de un servidor significa entregar una credencial activa a un tercero, que es justo lo que deberías evitar. Para la codificación que hay debajo de todo esto, consulta nuestra herramienta Base64, y explora el resto de nuestras herramientas para desarrolladores para descubrir más utilidades que funcionan en tu dispositivo.

Preguntas frecuentes