Decodificador JWT: decodificar, verificar y crear JSON Web Tokens
Pegue un token para ver el header, el payload y los claims en claro, saber si ha caducado y verificar la firma. El token, el secreto y las claves no salen de su dispositivo.
El token, el secreto y las claves se procesan solo en esta página: no se envían, no se añaden a la URL ni a la analítica.
header · payload · firma
Verificar firma
Algoritmo:—Es la única petición de red de la página y solo se envía al pulsar el botón.
Comprobaciones
Header
Payload
Claims
El codificador firma con HMAC (HS256, HS384, HS512). Es para tokens de prueba: no introduzca secretos de producción en un ordenador compartido.
Token firmado
¿Desarrolla API con autenticación por tokens?
Diseñamos y desarrollamos API, flujos OAuth 2.0 y OpenID Connect y los probamos frente a vulnerabilidades. Cuéntenos su proyecto y reciba una estimación.
¡Gracias! Le responderemos en un día laborable.
En resumen: pegue un JSON Web Token arriba. El decodificador muestra el header y el payload como JSON formateado, explica los claims estándar, indica si el token ha caducado y verifica la firma con su secreto o su clave pública. En la pestaña Codificador se crean tokens HS256, HS384 y HS512 para pruebas. Todo ocurre en el navegador.
Creamos este decodificador JWT para nuestro propio trabajo con API y autenticación en YuSMP Group. Si necesita un equipo que diseñe la autenticación con tokens o revise su seguridad: desarrollo de API y pruebas de penetración y auditorías de seguridad.
¿Qué es un JWT?
Un JSON Web Token (RFC 7519) es una cadena compacta de tres partes en Base64URL separadas por puntos: header.payload.signature. El header indica el algoritmo de firma (alg) y a veces el identificador de clave (kid). El payload contiene los claims: quién emitió el token, para quién es y cuándo caduca. La firma demuestra que nadie modificó las dos primeras partes. El payload está codificado, no cifrado: cualquiera que tenga el token puede leerlo.
Cómo decodificar y verificar un JWT
- Pegue el token en el campo «Token codificado». El prefijo
Bearery los saltos de línea se eliminan solos. Las tres partes aparecen en colores: header, payload, firma. - Lea el resultado. El header y el payload se muestran como JSON formateado. El bloque Claims convierte
exp,iatynbfen fechas UTC y de su zona horaria y muestra «caducó hace 10 minutos» o «caduca dentro de 3 horas». - Revise los avisos. La herramienta marca
alg: none, tokens caducados o aún no válidos, la falta deexp, tiempos en milisegundos y campos que parecen datos personales. - Verifique la firma. Para HS256/384/512 introduzca el secreto compartido como texto o Base64. Para RS, PS, ES y EdDSA pegue la clave pública en PEM, un certificado X.509, un JWK o un JWKS completo, o cargue el JWKS por URL: la clave correcta se elige por
kid.
¿Qué algoritmos se admiten?
- HMAC — HS256, HS384, HS512: secreto compartido (texto o Base64).
- RSA — RS256, RS384, RS512, PS256, PS384, PS512: clave pública RSA: PEM, PKCS#1, certificado, JWK.
- ECDSA — ES256, ES384, ES512: clave pública EC P-256, P-384 o P-521.
- EdDSA — Ed25519: clave pública Ed25519, si su navegador la admite.
La verificación usa la API WebCrypto integrada en el navegador. La comparamos, para cada algoritmo, con los ejemplos de la RFC 7515, con tokens de jwt.io y con tokens firmados con la biblioteca de Python cryptography.
Errores habituales con JWT
- Confiar en el payload sin verificar la firma. Decodificar no es validar: el servidor debe comprobar la firma,
exp,issyauden cada petición. - Aceptar
alg: noneo dejar que el token elija el algoritmo. Fije en el servidor el algoritmo esperado. - Un secreto HS corto. La RFC 7518 exige una clave al menos tan larga como el hash: 32 bytes para HS256, 64 para HS512. Un secreto corto se adivina sin conexión.
- Datos personales en el payload. Correo, teléfono o dirección en un JWT los puede leer cualquiera que vea el token, incluidas extensiones del navegador y registros.
- Milisegundos en
exp. Las fechas JWT van en segundos. Un valor como1735689600000equivale al año 56 971: el token no caduca nunca.
Preguntas frecuentes
¿Es seguro pegar aquí un token de producción?
El decodificador funciona por completo en el navegador: el token, el secreto y las claves no van a ningún servidor, ni a la URL, ni a la analítica. No se guarda nada si no marca «Recordar». Aun así, trate los tokens reales como contraseñas y, si puede, use tokens caducados o de prueba.
¿Qué diferencia hay entre decodificar y verificar un JWT?
Decodificar solo lee las partes Base64URL y muestra el JSON. Verificar vuelve a calcular la firma con el secreto o la clave pública y demuestra que el header y el payload no se han modificado. Un token puede decodificarse sin problemas y tener una firma no válida.
¿Por qué dice «Firma no válida» si el token funciona en mi aplicación?
Casi siempre el secreto está en otra codificación: cambie entre Texto y Base64. En tokens RS y ES compruebe que la clave pública corresponde al kid del header. El secreto debe coincidir byte a byte con el del servidor, incluidos los saltos de línea.
¿Puedo verificar un token con la URL de un JWKS?
Sí. Pegue la URL del JWKS (por ejemplo, /.well-known/jwks.json) y pulse «Cargar claves». Es la única petición de la página y solo con ese botón. Si el servidor no permite peticiones desde el navegador (CORS), abra la URL usted mismo y pegue el JSON en el campo de clave.
¿Puedo crear un JWT con esta herramienta?
Sí, en la pestaña Codificador. Edite el JSON del header y del payload, elija HS256, HS384 o HS512 e introduzca un secreto. Los botones ponen iat en el momento actual y exp una hora después. El token firmado se puede copiar o abrir en el decodificador.
¿Admite tokens cifrados (JWE)?
No. Un JWE tiene cinco partes y un payload cifrado que no se puede leer sin la clave privada. El decodificador reconoce estos tokens y lo indica.