Un JWT (JSON Web Token) es una credencial compacta y firmada que viaja como una cadena de texto. Se usa sobre todo como token de acceso en APIs, logins y OAuth 2.0 / OpenID Connect: el cliente lo manda en cada petición en la cabecera Authorization: Bearer … y el servidor comprueba la firma para saber quién eres y qué puedes hacer sin consultar una base de datos. La firma garantiza que nadie lo ha manipulado, pero no cifra su contenido: cualquiera puede leerlo (esta misma herramienta lo hace).

Un JWT tiene tres partes separadas por puntos: header.payload.signature.

• Header (cabecera) — JSON con el algoritmo de firma (alg) y el tipo (typ: JWT); a veces un kid que identifica la clave usada.
• Payload (carga) — JSON con los claims: los datos del token (usuario, permisos, caducidad…).
• Signature (firma) — el resultado de firmar header.payload con el algoritmo del header.

El header y el payload van codificados en Base64URL (no es cifrado, solo texto seguro para URLs). Esta herramienta los decodifica a JSON legible y colorea las tres partes.

Dos formas de trabajar:

• Decodificar — pega un token en la pestaña Decodificar y verás al instante el header, el payload y una tabla de claims con su significado y su caducidad. No hace falta la clave para leerlo.
• Crear — en la pestaña Crear escribes el payload (JSON), eliges algoritmo, aportas el secreto o la clave privada y obtienes un token firmado.

El token recién creado lo pasas con un clic a Verificar o al visualizador de flujo de autenticación. Todo ocurre en tu navegador: ni tokens ni claves salen de tu equipo.

El campo alg del header dice con qué algoritmo se firmó. Esta herramienta soporta 12, en tres familias; el número es el tamaño del hash SHA (256/384/512).

• HS256 / HS384 / HS512 (HMAC + SHA) — simétricos: la misma clave secreta firma y verifica. Sencillos y rápidos. Úsalos cuando quien firma y quien verifica son la misma parte o comparten el secreto de forma segura (p. ej. un backend que emite y consume sus propios tokens). Inconveniente: cualquiera que pueda verificar también puede falsificar.
• RS256 / RS384 / RS512 (RSA PKCS#1 v1.5 + SHA) — asimétricos: se firma con la clave privada y se verifica con la clave pública. Los más extendidos en OAuth/OIDC: el emisor guarda la privada y publica la pública (JWKS) para que cualquiera verifique sin poder falsificar. Claves grandes (2048 bits) y firma más lenta.
• PS256 / PS384 / PS512 (RSA-PSS + SHA) — RSA asimétrico como RS, pero con relleno PSS (probabilístico), considerado más robusto. Elígelo si tu plataforma lo admite y quieres el RSA moderno.
• ES256 / ES384 / ES512 (ECDSA + curvas P-256/P-384/P-521) — asimétricos de curva elíptica: mismas garantías que RSA pero con claves y firmas mucho más pequeñas y rápidas. Buena opción por defecto para tokens nuevos.

Regla práctica: HS* si compartes un secreto en un entorno controlado; ES* o RS*/PS* si terceros deben verificar sin poder emitir.

En Verificar se comprueba la firma de verdad (criptografía Web Crypto del navegador):

• Elige el algoritmo (se preselecciona el que declara el header).
• Si es HS*, pega el secreto. Si es RS/PS/ES*, pega la clave pública en PEM (-----BEGIN PUBLIC KEY-----) o JWK (JSON); la herramienta detecta cuál es.
• Verás Firma válida o inválida, más los chequeos de caducidad (exp) y de «ya válido» (nbf).

Dos protecciones clave: se rechaza siempre alg:none (tokens sin firmar) y se avisa de la confusión de algoritmo — verificar como HMAC un token asimétrico (o al revés) es un fallo de seguridad conocido. La clave nunca sale de tu equipo.

En Crear construyes y firmas un token:

• Escribe el payload como JSON; con los chips añades rápido claims estándar (sub, iss, aud, exp…) o comunes (name, role, scope…) con valores de ejemplo.
• Elige el algoritmo y aporta el secreto (HS*) o la clave privada PEM/JWK (RS/PS/ES*). Opcional: un kid en el header.
• Generar claves crea al momento un secreto aleatorio (HMAC) o un par de claves (privada + pública en PEM y JWK) para pruebas.
• Firma y copia el token. Con un clic lo llevas a Verificar (round-trip) o al flujo de autenticación.

Los claims son los campos del payload. Los registrados (RFC 7519) tienen significado estándar:

• iss — emisor: quién creó el token.
• sub — sujeto: a quién identifica (normalmente el usuario).
• aud — audiencia: para quién es; el receptor debe estar en ella.
• exp — expiración: instante tras el cual deja de valer.
• nbf — no antes de: no vale hasta ese instante.
• iat — emitido en: cuándo se creó.
• jti — ID único: útil para revocación o anti-replay.

Los tiempos van en segundos Unix (segundos desde 1970). La herramienta los muestra como fecha local y en relativo («hace 3 h», «dentro de 42 min») y marca en rojo si el token está caducado (exp pasado) o aún no vale (nbf futuro). Ojo: decodificar no valida — la caducidad solo obliga si el servidor la comprueba al verificar.

La pestaña Probar authz simula la decisión de un gateway o API: defines las reglas que exigirías (emisor, audiencia, scopes/roles) y la herramienta contrasta el token pegado y muestra ALLOW o DENY regla por regla, indicando qué falta o no coincide (incluidas exp y nbf). Sirve para entender por qué un token sería aceptado o rechazado sin montar el backend.

Puntos clave:

• La firma prueba integridad y origen, pero no cifra: el payload es legible por cualquiera. Nunca metas datos sensibles (contraseñas, tarjetas…) en un JWT sin cifrado adicional (JWE).
• Trata los tokens como secretos: no los pegues en sitios públicos ni los guardes en repos. Los ejemplos de aquí usan secretos y claves de juguete; para producción usa claves reales generadas de forma segura y no las pegues en esta herramienta.
• Pon siempre exp (caducidad corta) y verifica en el servidor la firma y el algoritmo esperado. Rechaza alg:none y la confusión de algoritmo.
• Todo el trabajo es local en tu navegador: nada se envía a ningún servidor.