Codificador / decodificador JWT

¿Qué significa « decodificar un JWT »?

Decodificar un JWT (« jwt decode », « decode jwt online ») consiste en partir la cadena en tres por los puntos y decodificar después cada segmento en Base64URL para recuperar el JSON original. No hace falta ninguna clave: el encabezado y el payload están codificados, no cifrados. Esa es exactamente la intención detrás de « jwt payload decoder » o « decode jwt without verify »: ver qué contiene el token, sin pretender que sea auténtico.

Atención a distinguir bien las dos acciones. Leer un JWT no prueba nada: cualquiera puede fabricar un token con un payload atractivo y firmarlo con su propio secreto. Verificar la firma prueba que el contenido no ha sido modificado por un tercero. Un decodificador que muestra « admin: true » sin comprobar la firma te cuenta una historia, no un hecho.

Los tres segmentos de un JWT

La cadena se divide exactamente en tres partes separadas por puntos: header.payload.signature. El encabezado contiene como mínimo alg y typ, a veces kid para indicar qué clave se usó. El payload contiene los claims, esos pares clave-valor cuyo registro lleva el IANA. La firma cubre los dos primeros segmentos concatenados exactamente como están escritos: la más mínima modificación de un espacio o de un carácter rompe la comparación.

Toda la dificultad viene de que estos segmentos están en Base64URL y no en Base64: el signo más se convierte en guion, la barra diagonal en guion bajo, y el relleno = desaparece. Un decodificador Base64 clásico fallará por tanto en un JWT válido. La tabla « Base64URL frente a Base64 clásico » de la pestaña de referencia muestra precisamente esas sustituciones.

Cómo verificar una firma: HS256, RS256, ES256

Para un algoritmo HMAC — HS256, HS384, HS512 — el mismo secreto sirve para firmar y verificar: la herramienta recalcula HMAC(secret, base64url(header) + "." + base64url(payload)) y compara el resultado con la firma transportada. Es el caso más común y también el más peligroso: cualquier servicio que posea el secreto puede emitir un token. Un secreto de menos de 32 octetos, reutilizado entre entornos, basta para comprometer toda la cadena.

Para los algoritmos asimétricos — RS256, RS384, RS512, ES256, ES384, ES512, PS256 — solo necesitas la clave pública para verificar, lo que permite comprobar un token emitido por un tercero sin compartir nunca su secreto de firma. Pega la clave en formato PEM -----BEGIN PUBLIC KEY----- (SPKI); el resultado crudo de una exportación OpenSSL es directamente utilizable. Para ES256, la firma está en formato r||s crudo, el que espera WebCrypto.

Por último, cuidado con la alg confusion : si tu servicio espera RS256 pero acepta un token cuyo encabezado declara HS256, un atacante firmará con la clave pública — convertida en clave HMAC — y pasará la verificación. Fija en el servidor el algoritmo esperado; nunca lo leas del propio token.

exp, iat, nbf: las marcas de tiempo que atrapan

Estos tres claims son segundos Unix, sin milisegundos y sin zona horaria: iat a 1516239022 significa 2018-01-17T21:30:22Z. Dos errores se repiten sin parar: comparar con una fecha en milisegundos (valor diez mil veces demasiado grande) e interpretar un timestamp en local en vez de en UTC. La pestaña « Expiración » convierte en ambos sentidos, muestra el ISO 8601, la fecha local y el tiempo restante o transcurrido — ideal para detectar al instante un token « ya caducado » al segundo de reloj.

Alargar el tiempo de vida no sube el nivel de seguridad: un exp aplazado cambia el valor mostrado, no la firma. Si tienes que reemitir, vuelve a firmar el token con el secreto o la clave privada — eso es exactamente el papel de la pestaña « Codificar ».

Base64URL: por qué fallan los decodificadores clásicos

Base64URL (RFC 4648 §5) usa el alfabeto A-Z a-z 0-9 - _ y no admite relleno. Un payload de 20 caracteres produce a menudo una longitud no múltiple de cuatro tras eliminar el = : es normal, no una corrupción. Los caracteres - y _ son ambiguos para un ojo humano, lo que explica la mitad de los « tokens rotos » que se reportan. Nuestro decodificador acepta los dos alfabetos, mayúsculas y minúsculas mixtas, el relleno opcional y un prefijo Bearer.

Seguridad: lo que un JWT no hace

Un JWT no ofrece ni confidencialidad ni revocación. El payload es legible por todos: nunca un correo, un rol interno ni un dato personal que no aceptarías enviar en claro. Y un token firmado sigue siendo válido hasta exp incluso tras cerrar la sesión — hace falta una lista de revocación, un jti con seguimiento en el servidor, o tiempos de vida cortos con refresh token. Un buen hábito: exp corto (10 a 15 minutos), iat controlado, nbf alineado con iat, aud y iss verificados al recibirlos.

Recomendado para

Desarrolladores back-end y front-end (OAuth 2.0, OpenID Connect, API REST), integradores y DevOps (infraestructura de identidad, JWKS, rotación de claves), testers y pentesters (reescritura de claims, alg confusion, expiración), administradores de sistemas (depuración de un 401 inexplicable), estudiantes (entender Base64URL y WebCrypto) y cualquiera que necesite un decodificador JWT online rápido, completo y confidencial — junto con el codificador y decodificador Base64, el codificador y decodificador URL y el formateador JSON.

Decodificador JWT 100 % local: tu token nunca sale de tu ordenador

A diferencia de los decodificadores JWT online clásicos, no se transmite ninguna cadena: la decodificación, la verificación de firma y la codificación se ejecutan íntegramente en tu navegador mediante WebCrypto, sin bibliotecas de terceros ni peticiones de red. Así se puede inspeccionar un token de sesión real, una clave de staging o un token de servicio interno sin riesgo, incluso sin conexión o en una red pública. El historial y la última entrada se guardan localmente (localStorage) y permanecen en tu dispositivo.

La licencia Premium Volade añade una sincronización en la nube opcional, cifrada e independiente de la herramienta — el resto sigue siendo gratuito e ilimitado, sin registro.