Codificador JWT
Crea un token a partir de claims y fírmalo de verdad · se ejecuta en esta pestaña, nunca se envía a ninguna parte
Cabecera
Payload
Clave de firma
La clave se usa y se descarta: nunca se guarda en este navegador ni se envía a ninguna parte.
Una clave de firma acuña tokens que tus sistemas aceptarán. Para una clave de producción, mejor tu propio entorno.
HS256
Token firmado
Aquí aparece el token firmado. No se sube nada para producirlo: la firma la calcula este navegador.
Cómo funciona el Codificador JWT
Un codificador de JWT que produce un token realmente firmado, no una imitación en base64. Escribe la cabecera y el payload como JSON, elige un algoritmo y pega el secreto compartido para un algoritmo HS o una clave privada PKCS#8 para RS, PS o ES: la firma la calcula la propia WebCrypto de tu navegador. La caducidad, la fecha de emisión y el «no antes de» se pueden estampar desde presets, así que no volverás a convertir un epoch a mano.
Escribe la cabecera y el payload como JSON, elige un algoritmo y el token se ensambla y se firma mientras escribes. Los presets de caducidad estampan iat, exp y opcionalmente nbf en el payload desde un mismo instante, de modo que los tres nunca puedan discrepar por un segundo — el tipo de cosa que solo falla dentro de la tolerancia de desfase de reloj de otra persona.
alg siempre se escribe a partir del algoritmo que elegiste, diga lo que diga tu cabecera. No es una comodidad: una cabecera que declara un algoritmo sobre una firma hecha con otro es el punto de partida de la vulnerabilidad más conocida de JWT, y no hay ningún token legítimo que esta herramienta se niegue a crear por ello. Cualquier otro campo de cabecera que escribas se conserva exactamente como lo escribiste.
Los secretos HS más cortos que el hash se rechazan por defecto — la RFC 7518 exige 32 bytes para HS256, 48 para HS384 y 64 para HS512, y un navegador firmará con cuatro caracteres tan tranquilo aunque el resultado se pueda romper sin conexión en segundos. La comprobación se puede desactivar, porque reproducir un token débil es a veces justo lo que se busca.
La clave de firma se trata como el decodificador trata su clave de verificación, y aún con más cuidado: nunca se escribe en localStorage, nunca se restaura al recargar, nunca aparece en un evento de analítica, y no hay backend que pudiera recibirla. Una clave de firma es el secreto más peligroso de un sistema que usa JWT, así que para una clave de producción sigue siendo mejor costumbre acuñar los tokens en tu propio entorno.
Preguntas frecuentes
¿Es seguro pegar una clave de firma en este codificador?
La clave se usa en tu propia pestaña y se descarta: nunca se guarda en el almacenamiento, nunca entra en un evento de analítica y no hay backend que pudiera recibirla. Dicho eso, una clave de firma es el secreto más peligroso de cualquier sistema que use JWT, porque quien la tenga puede acuñar tokens que tus servicios aceptarán. Para una clave de producción, generar los tokens en tu propio entorno sigue siendo mejor costumbre; esta herramienta está pensada para desarrollo, pruebas y aprendizaje.
¿Con qué algoritmos puede firmar?
HS256, HS384 y HS512 con un secreto compartido, y RS256/384/512, PS256/384/512 y ES256/384/512 con una clave privada en bloque PEM PKCS#8 o como JWK privado. También produce el token no asegurado con `alg: none`, claramente marcado como algo que no demuestra nada, porque reproducir uno es la forma de comprobar que tu verificador lo rechaza.
¿Por qué rechaza mi secreto corto?
La RFC 7518 exige una clave HMAC al menos tan larga como el hash: 32 bytes para HS256, 48 para HS384 y 64 para HS512. Los navegadores firman tan tranquilos con un secreto de cuatro caracteres, y el token resultante se rompe sin conexión en segundos. El codificador lo bloquea por defecto y te deja saltártelo, ya que reproducir un token débil es a veces justo lo que hace falta.
¿Puede sobrescribir el algoritmo de mi cabecera?
Siempre escribe `alg` a partir del algoritmo que elegiste, y es deliberado. Una cabecera que declara un algoritmo sobre una firma hecha con otro no es un token: es el punto de partida de la vulnerabilidad de JWT más conocida. Cualquier otro campo de cabecera que escribas —`kid`, `cty`, lo que sea— se conserva tal cual.