Skip to content

Decodificador y Verificador JWT

En el navegador · consultas a APIs públicas
Última verificación junio 2026 — corre en tu navegador
Tu token nunca sale de tu navegador. Toda la decodificación se realiza localmente.
Verificar Firma

Se verifica mientras escribes. Tu clave nunca sale de tu navegador.

Pega un JWT arriba para activar la verificación de firma.

Decodificador JWT Online — Parser y Verificador

Pega un JWT para decodificar instantáneamente su cabecera, payload y firma. Las marcas de tiempo (exp, iat, nbf) se convierten a fechas legibles y los tokens expirados se señalan. Pega un secreto compartido o una clave pública PEM para verificar la firma en el navegador — HS256, RS256 y ES256 son compatibles vía Web Crypto API. El algoritmo inseguro alg=none se rechaza explícitamente.

Cómo decodificar y verificar un JWT

  1. Pega el token JWT en la caja de entrada. La herramienta lo parte en header, payload y signature y decodifica las dos primeras partes.
  2. Revisa los claims (exp, iss, sub, aud) para comprobar la validez y origen del token. Los expirados se marcan automáticamente.
  3. Opcional: pega el secreto compartido (HS256) o la clave pública PEM del emisor (RS256/ES256) en el panel Verificar para confirmar que la firma es auténtica.
  4. La verificación corre localmente con la Web Crypto API — tu secreto o clave nunca se envía a ningún sitio. Un badge verde confirma la firma; un banner rojo explica por qué falló (firma no coincide, alg=none, formato de clave inválido).

Casos de uso comunes

  • Depurar una respuesta 401 inspeccionando qué claims está enviando el cliente.
  • Comprobar si un JWT está expirado antes de culpar al servidor por un bug de auth.
  • Auditar el payload de un token por fuga involuntaria de PII en sus claims.
  • Verificar un token emitido por un servicio externo pegando su clave pública JWKS.
  • Leer el parámetro JWT de una URL firmada para entender qué acceso concede.

Preguntas frecuentes

¿Puede verificar la firma?

Sí. Pega el secreto compartido (HS256) o la clave pública PEM del emisor (RS256, ES256) en el panel Verificar. La verificación corre en el navegador usando la Web Crypto API — tu clave nunca se transmite. El algoritmo inseguro alg=none se rechaza explícitamente incluso si pegas una clave.

¿Qué algoritmos son compatibles para verificación?

HS256 (HMAC-SHA-256), RS256 (RSASSA-PKCS1-v1_5 con SHA-256) y ES256 (ECDSA P-256 con SHA-256). Cubren la inmensa mayoría del tráfico JWT. Otros algoritmos (HS512, RS384, ES384, EdDSA, etc) se marcan como no compatibles en vez de fallar en silencio — verás el nombre exacto del alg en el error para poder verificarlo con otra herramienta.

¿Qué significa 'exp'?

Tiempo de expiración (Unix timestamp, RFC 7519 §4.1.4). Si exp está en el pasado, el token está expirado y el servidor debería rechazarlo. Relojes desincronizados son causa común de rechazos falsos positivos.

¿Por qué se rechaza alg=none?

Los tokens con alg=none no tienen protección criptográfica — cualquiera puede crearlos o modificarlos. Aceptar alg=none es una vulnerabilidad JWT bien conocida (CVE-2015-9235 y muchas secuelas). El verificador aquí rechaza estos tokens incondicionalmente para que no valides uno por accidente.

¿Es seguro pegar un JWT de producción aquí?

La decodificación ocurre en tu navegador y la verificación con Web Crypto también es local — ni el token ni la clave se envían por la red. Aun así, trata cualquier JWT de producción como una credencial: nunca pegues un token que no hayas rotado ya o que pertenezca a otro usuario, y asume que las extensiones del navegador pueden leer tus pestañas.

¿Se guarda mi token o clave?

No. La decodificación y la verificación corren localmente y todo se descarta al salir de la página. No hay almacenamiento en servidor ni analítica de terceros sobre estos campos.

Cómo Decodificar JWT Online (Parser y Verificación)

Un JWT consiste en tres partes codificadas en Base64URL separadas por puntos: cabecera (algoritmo y tipo — RFC 7519 §5), payload (claims como sujeto, expiración y datos personalizados — §4) y firma (RFC 7515 / JWS). Los JWT se usan ampliamente para autenticación y autorización de APIs. La firma es lo que prueba que un token no ha sido manipulado — sin verificarla contra el secreto o la clave pública del emisor, los claims decodificados nunca deberían considerarse fiables.

  • Decodificación de la cabecera (algoritmo, tipo)
  • Inspección del payload con JSON formateado
  • Marcas de tiempo legibles
  • Detección de expiración
  • Verificación de firma (HS256, RS256, ES256) vía Web Crypto
  • alg=none rechazado explícitamente — se niega a validar tokens sin firma
  • Secciones con código de colores (cabecera, payload, firma)
  • Copiar secciones individuales
  • Token de ejemplo para pruebas
  • Privacidad ante todo: token y clave nunca salen de tu navegador

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (3)
  • Jones, M., Bradley, J., & Sakimura, N. (2015). JSON Web Token (JWT). RFC 7519, IETF.
  • Jones, M., Bradley, J., & Sakimura, N. (2015). JSON Web Signature (JWS). RFC 7515, IETF.
  • Jones, M. (2015). JSON Web Algorithms (JWA). RFC 7518, IETF.

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Por ·