ToolsOps

Seguridad

Decodificador y verificador de JWT (HS256, RS256, ES256)

Pega un JWT y la herramienta separa header, payload y firma, decodifica base64url y muestra el JSON con resaltado. Interpreta los claims temporales (iat, nbf, exp) en tu zona horaria local y marca si el token está vigente. Para verificar la firma, pega tu secret HMAC o tu clave pública en PEM o JWK. La verificación corre localmente con Web Crypto API; ningún token, secret ni clave se envía a un servidor.

El token se procesa localmente. No se envía a ningún servidor.
El enlace serializa solo opciones de UI (pestaña, filtro de algoritmo, formato del secret). Nunca incluye el token, secret ni claves.

Ejemplos

  • Pega un JWT y la pestaña Decodificar separa las tres partes.Decodificar header y payload
  • Cambia a Verificar firma, formato UTF-8, pega el secret compartido.Verificar HS256
  • Pega la clave pública dentro de -----BEGIN PUBLIC KEY-----.Verificar RS256 con PEM
  • Pega el JWK del JWKS de tu identity provider ({"kty":"EC","crv":"P-256",...}).Verificar ES256 con JWK
  • Mira el badge junto a exp en el panel de claims.Comprobar expiración

Preguntas frecuentes

¿Mis datos salen del navegador?
No. La decodificación se hace con atob y JSON.parse locales; la verificación de firma se hace con Web Crypto API en tu navegador. Ningún token, secret ni clave se envía a un servidor. Puedes confirmarlo abriendo DevTools en la pestaña Network mientras usas la herramienta.
¿Por qué decodificar no es lo mismo que verificar?
Decodificar un JWT solo lee su contenido leyendo base64url. Cualquiera puede construir un JWT con los claims que quiera. Lo que importa para confiar en un token es que su firma sea válida con la clave correcta. Para esto, usa el panel 'Verificar firma' con el secret o la clave pública adecuada.
¿Qué algoritmos soporta la verificación?
HS256, HS384 y HS512 (HMAC con secret compartido). RS256, RS384 y RS512 (RSA con clave pública en PEM o JWK). ES256, ES384 y ES512 (ECDSA sobre P-256, P-384 y P-521 respectivamente). El RFC también define `alg: none`, que la herramienta rechaza activamente porque es un vector de ataque histórico.
¿Por qué se rechaza `alg: none`?
RFC 7515 §4.1.1 permite `alg: none` para tokens sin firma, pero en la práctica es una de las causas más comunes de bypass de autenticación: una biblioteca acepta el token sin verificar nada cuando el header dice none. La herramienta nunca marca un token con `alg: none` como firma válida, sin importar lo que pegues en el campo secret/key.
¿Qué pasa si el token está expirado?
El claim exp se renderiza como timestamp en tu hora local y se etiqueta con el delta (expiró hace 3 horas). La firma criptográfica puede seguir siendo válida, pero un servidor que respete RFC 7519 debe rechazar un token expirado. La herramienta señala ambos hechos por separado para que sepas distinguir entre firma OK y token aceptable.
¿Puedo pegar el secret en hex o base64 en lugar de UTF-8?
Sí. El selector 'Formato del secret' permite cambiar entre UTF-8 (default, lo que ves), hex (pares hexadecimales) y base64. Para HS256 con clave generada con `openssl rand -base64 32`, lo natural es base64.
¿Soportáis JWE (tokens cifrados)?
No en v1. JWE (5 partes, payload cifrado) requiere desencriptado simétrico/asimétrico además de verificación. Se evalúa para una iteración posterior si la demanda real (medida en GSC) lo justifica. La herramienta detecta el formato JWE de 5 partes y muestra un mensaje claro de no soportado.
¿Dónde debería guardar un JWT en mi aplicación?
Para el caso típico de web tradicional: cookie HttpOnly con Secure y SameSite Lax o Strict. Evita localStorage por exposición a XSS. Para SPAs con backend separado: cookie HttpOnly cuando sea posible; si no, access token en memoria y refresh token en cookie HttpOnly. La guía editorial 'Buenas prácticas con JWT' cubre este tema con más detalle.