Decodificador JWT (header, payload, firma, expiración)
Pega un JWT para decodificar al instante header y payload como JSON. Reconoce claims estándar (iat, exp, nbf) y convierte timestamps Unix a ISO 8601. Marca tokens expirados o aún no válidos.
Decodificado enteramente en tu navegador. El token no viaja por la red.
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"sub": "1234567890",
"name": "Jane Doe",
"iat": 1730000000,
"exp": 4886000000
}- Firma presente
- ✓
- Emitido en (iat)
- 2024-10-27T03:33:20.000Z
- Expira en (exp)
- 2124-10-30T22:13:20.000Z
Cómo funciona
Cómo se ve un JWT
Un JWT son tres segmentos codificados en Base64url unidos por puntos: header.payload.signature. Cada segmento es un objeto JSON codificado para transmisión URL-safe. El header declara el algoritmo de firma, el payload lleva claims (sujeto, expiración, datos custom), y la firma permite al receptor verificar integridad si tiene la clave.
Este decodificador lee solo los dos primeros segmentos. La firma es el tercero pero verificarla requiere la clave secreta/pública — operación separada que no hacemos aquí.
Claims estándar a conocer
iss (issuer): quién creó el token. iat (issued at): cuándo, como timestamp Unix. exp (expiry): cuándo deja de ser válido, también Unix. nbf (not before): el momento más temprano en que debe respetarse. sub (subject): la entidad que representa, a menudo un user ID. aud (audience): a quién va dirigido, normalmente una URL de servicio.
No todos son obligatorios; los JWTs mínimos suelen tener solo sub + iat + exp. Los claims custom son cualquier otra cosa — viven junto a los estándar en el payload.
Por qué decodificar ≠ verificar
Cualquiera puede decodificar un JWT — header y payload son solo JSON Base64. Por eso decimos 'nunca pongas secretos en el payload': son efectivamente públicos.
Verificar significa comprobar la firma contra la clave secreta (HMAC) o pública (RSA/ECDSA). Sin verificación no puedes confiar en ningún claim del payload — un atacante puede falsificar cualquier payload.
Usa esta herramienta para inspeccionar tokens al depurar. Usa una librería JWT en tu servidor para verificarlos en producción.
Preguntas frecuentes
›¿Puedo verificar la firma aquí?
No — la verificación necesita la clave secreta o pública, que nunca debe salir de un entorno confiable. Usa una librería JWT en servidor (jsonwebtoken para Node, PyJWT para Python, etc.).
›¿El token sale del navegador?
Nunca. La decodificación corre localmente; no tenemos endpoint de servidor que lo reciba.
›¿Por qué mi token es 'inválido'?
Comunes: el copy-paste añadió/quitó whitespace, falta uno de los tres segmentos, o un segmento es Base64url malformado. Recórtalo y reintenta.
›¿Base64url vs Base64?
Base64url sustituye '+' por '-', '/' por '_', y elimina el padding '=' para que el string codificado sea seguro en URLs y headers HTTP. Los JWTs siempre usan Base64url.
›¿Por qué mi payload Unicode aparece confuso?
Decodificamos UTF-8 (estándar). Si el payload se codificó distinto, JSON.parse falla. La mayoría de emisores JWT codifican UTF-8 correctamente.
›¿HS256 es seguro?
Si el secreto es suficientemente largo (≥256 bits) y se mantiene secreto, sí. Vulnerabilidades comunes de HS256: secretos débiles y aceptar tokens con alg='none'. Usa secretos aleatorios ≥32 chars y rechaza 'none' explícitamente.
›¿Por qué preferir RS256 sobre HS256?
RS256 (RSA asimétrico) te deja publicar una clave pública para verificar mientras mantienes la privada en secreto. HS256 (HMAC simétrico) requiere compartir el secreto con cada verificador. Para arquitecturas multi-servicio, RS256 es más seguro.
›¿Puedo decodificar tokens enormes?
Límite práctico ~10 MB; más allá el navegador se ralentiza. Los JWT suelen ser <4 KB; si el tuyo es mayor, considera si guardas demasiado en claims.
Herramientas relacionadas
Última actualización: