JWT encode/decode: crear e inspeccionar un token en línea

El decodificador y el codificador cubren todo lo que no exige establecer confianza en un emisor.

Confiar en un token requiere claves, claims y una política, no solo un payload legible. Pasa a jwt-verify, a inspect-jwks o a tu propio código.

Pega el token en el decodificador y lee los claims de tiempo antes de tocar la API. exp, nbf e iat son valores NumericDate: segundos desde el 1 de enero de 1970 UTC (RFC 7519).

Cuando los claims son correctos y la API rechaza igualmente, el problema está en la cabecera o en la firma.

Un 403 significa que el token se aceptó y la autorización dijo que no. El payload suele explicar por qué.

Un decodificador muestra lo que un token afirma, no quién lo escribió. El payload no está protegido: quien tiene el token, o puede fabricar uno, puede meter cualquier claim. El codificador puede incluso producir un token no seguro con alg=none, cuyo segmento de firma está vacío: las herramientas lo etiquetan como «JWT sin firmar (alg=none)», y ningún verificador debería aceptarlo jamás. La RFC 8725 (buenas prácticas para JWT) pide a los servidores aceptar solo los algoritmos esperados y no dejar nunca que el token elija. La confusión de algoritmo es el fallo clásico: un token que declara HS256 y está firmado con la clave pública de un servicio RS256 pasa un verificador que lee alg de la cabecera y usa la clave pública como secreto HMAC.

Base64URL es una codificación, no un cifrado: la guía de Base64 explica la diferencia. Un JWT firmado (JWS) solo garantiza la integridad, así que todo el payload es legible. Existen tokens cifrados (JWE, RFC 7516, cinco partes en lugar de tres), pero el decodificador de aquí solo trata tokens firmados. Un token es además una credencial: quien lo tiene puede usarlo hasta exp. Esta herramienta lo mantiene en tu pestaña, pero compartir pantalla, una captura compartida o un ticket con el token pegado lo filtran igualmente.

HS256 firma con un secreto compartido, y la RFC 7518 pide una clave al menos tan larga como la salida del hash: 256 bits para HS256, 384 para HS384, 512 para HS512. Cuando tu secreto es más corto, el codificador muestra su tamaño en bits frente al mínimo recomendado. Esa cifra es la longitud de la clave, no su aleatoriedad: una frase de 32 caracteres en español mide 256 bits de largo y sigue siendo adivinable. Quien posee un solo token puede probar secretos candidatos sin conexión contra su firma, sin tocar nunca tu API. Genera el secreto al azar, por ejemplo con el generador de contraseñas (consulta la guía de contraseñas): unos 41 caracteres de su juego por defecto de 82 caracteres aportan 256 bits de entropía. La opción Base64URL cambia los bytes usados: marcada, la cadena del secreto se decodifica como Base64URL y sus bytes son la clave; sin marcar, los propios caracteres son la clave. El mismo texto con el ajuste equivocado da otra firma.

El codificador está pensado para fixtures y depuración. Reescribe iat a ahora, puede suprimir la firma por completo y los ejemplos que carga usan secretos desechables. Un token firmado aquí con un secreto de demostración nunca debe ser aceptado por un entorno real, y un secreto de firma real nunca debe pegarse en un archivo que luego subas al repositorio. Si ya ocurrió, cámbialo y analiza tu diff antes de hacer commit con el escáner de secretos.

La forma compacta son tres segmentos Base64URL unidos por puntos. Es lo que viaja en una cabecera Authorization: Bearer.

Siete claims registrados (RFC 7519) cubren la mayoría de las sesiones de depuración. Todos son opcionales en la especificación, así que una API puede exigir más que el estándar.

El valor de alg decide quién puede emitir un token y quién solo puede comprobarlo.

El decodificador JWT no tiene botón: la decodificación se ejecuta mientras pegas o editas, tras una breve pausa. El editor empieza vacío; «Cargar ejemplo» o elegir un algoritmo carga un token de demostración.

El codificador JWT firma mientras escribes. El token aparece en cuanto la cabecera, el payload y la clave son válidos.

Algunos límites que conviene conocer antes de apoyarse en ellas para un uso concreto.

Decodificar no requiere biblioteca: divide por los puntos y lee cada segmento como Base64URL. Es lo que hace el decodificador, con el mismo límite: no se comprueba nada.

La biblioteca jose firma un JWT compacto y rellena los claims registrados por ti. A diferencia del codificador de aquí, setIssuedAt() usa el reloj real, como corresponde en producción.

La verificación es donde se establece la confianza: fija el algoritmo, el emisor y la audiencia, y permite una pequeña tolerancia de reloj.

Nada que instalar y nada enviado: el decodificador y el codificador cubren la lectura de claims, la creación de fixtures y la comprobación de una firma de la que tienes la clave. Las contrapartidas: sin validación de claims, sin conversión de marcas de tiempo, sin JWE, EdDSA limitado a Ed25519. Para una decisión de confianza real, usa una biblioteca de verificación en el servidor, o pega un JWKS en jwt-verify para probar antes tu política.