Decodificador de JWT
Decodifica cualquier JSON Web Token para inspeccionar su encabezado, su payload y sus claims en un formato legible y, si quieres, verifica una firma HMAC (HS256/384/512). Todo permanece en tu navegador.
Cómo usar Decodificador de JWT
- 1
Pega tu token
Pega un JSON Web Token codificado en el campo de entrada. El decodificador lo divide automáticamente en encabezado, payload y firma.
- 2
Lee los claims
Inspecciona el encabezado y el payload decodificados como JSON formateado y revisa los claims registrados, como la expiración y la fecha de emisión, mostrados como fechas legibles.
- 3
Verifica la firma
Para los tokens HMAC, ingresa el secreto de firma para confirmar que la firma es válida y que el token no ha sido manipulado.
- 4
Copia lo que necesites
Copia el JSON formateado del encabezado o del payload al portapapeles para usarlo en pruebas, documentación o depuración.
Entender los JSON Web Tokens: anatomía, claims y errores frecuentes
Tres partes separadas por puntos
Un JSON Web Token es una sola cadena larga con dos puntos en su interior, que la dividen en tres segmentos: encabezado, payload y firma. Cada uno de los dos primeros segmentos es un pequeño objeto JSON que se ha codificado en Base64URL, una variante de Base64 segura para URL que intercambia un par de caracteres y prescinde del relleno para que el token viaje sin problemas en encabezados y cadenas de consulta. El tercer segmento es la firma, calculada sobre los dos primeros.
Pega un token y el decodificador lo divide por los puntos y decodifica de Base64URL las dos primeras partes para devolverlas a un JSON legible. Verás el encabezado y el payload exactamente como los escribió el emisor. La razón de que esto sea posible es la clave de todo lo que sigue: esos segmentos están simplemente codificados, no cifrados.
El encabezado: algoritmo y tipo
El encabezado es la parte más pequeña. Normalmente declara el tipo —JWT— y, lo que es más importante, el algoritmo de firma en su campo alg. Los valores habituales son HS256, que usa un HMAC con un secreto compartido, y RS256 o ES256, que usan pares de claves asimétricas en los que una clave privada firma y una clave pública verifica. El algoritmo le indica al verificador cómo se produjo la firma y, por tanto, cómo comprobarla.
El campo alg también es relevante para la seguridad. Un token que declare un algoritmo none, o un atacante que cambie un token de un algoritmo asimétrico a uno simétrico para engañar a un verificador ingenuo y hacer que use la clave pública como secreto HMAC, son ataques clásicos. Un verificador correcto fija el algoritmo que espera en lugar de confiar a ciegas en lo que diga el encabezado.
El payload y sus claims registrados
El payload transporta los claims, es decir, las afirmaciones que hace el token. Hay un conjunto de nombres de claims registrados que está estandarizado para que distintos sistemas coincidan en su significado. El claim de emisor (iss) indica quién creó el token, el claim de sujeto (sub) identifica a quién o a qué se refiere (a menudo un ID de usuario), y el claim de audiencia (aud) nombra al destinatario previsto. Junto a estos sueles encontrar claims de aplicación personalizados, como un rol o un tenant.
Este decodificador muestra los claims registrados de forma etiquetada y legible para que no tengas que reconocer de memoria los crípticos nombres abreviados. Ver el emisor, el sujeto y la audiencia escritos con todas sus letras suele ser todo lo que necesitas cuando inspeccionas un token a ojo durante la depuración para confirmar que es el correcto para el servicio correcto.
Claims de tiempo: exp, iat y nbf
Tres claims gobiernan la vida útil de un token, y todos ellos son timestamps Unix medidos en segundos, no en milisegundos, lo que supone un frecuente error de un factor de mil para los desarrolladores de JavaScript acostumbrados al tiempo en milisegundos. El claim de expiración (exp) es el instante a partir del cual el token debe rechazarse, el claim de emisión (iat) registra cuándo se creó, y el claim not-before (nbf) marca el primer momento en que pasa a ser válido.
El decodificador los convierte en fechas legibles y te dice si el token está activo, aún no es válido o ha expirado según el reloj de tu dispositivo. Ese último detalle importa: si el reloj de tu equipo está mal, el veredicto de activo o expirado puede inducir a error, y en producción un desfase de reloj entre servidores es un motivo habitual de que un token recién emitido se rechace por no ser aún válido.
Decodificar no es verificar
Esto es lo más importante que debes interiorizar. Cualquiera puede decodificar un JWT —no es más que Base64URL—, así que leer los claims te dice lo que el token afirma, no si el token es auténtico. La confianza solo proviene de comprobar la firma contra la clave, lo que demuestra que el token lo emitió una parte que posee el secreto o la clave privada y que no se ha alterado desde entonces.
Para los tokens HMAC (HS256, HS384, HS512), esta herramienta puede recalcular la firma a partir del encabezado, el payload y el secreto que proporciones, y compararla con la firma del token, confirmando la autenticidad para ese secreto. Los algoritmos asimétricos como RS256 y ES256 requieren la clave pública del emisor y aquí se decodifican pero no se verifican. Es crucial entender que las decisiones de autorización reales deben verificar la firma en el servidor; nunca confíes en los claims de un token basándote solo en la decodificación dentro del código del cliente.
El payload no es secreto
Como el payload solo está codificado, todos los claims que contiene quedan a la vista de cualquiera que obtenga el token: el navegador, cualquier proxy, el propio usuario. Un JWT es un sitio estupendo para datos de identidad y autorización no sensibles, y un sitio pésimo para cualquier cosa confidencial. Nunca pongas una contraseña, un secreto de API, un número de tarjeta de crédito o datos personales privados en el payload pensando que la codificación los protege. No lo hace.
La firma protege la integridad, no la confidencialidad: impide la manipulación, pero no hace nada por ocultar el contenido. Si realmente necesitas un token cifrado cuyo payload no pueda leerse, eso es una construcción distinta y más pesada (JWE); un JWT estándar está firmado, no cifrado. En su lugar, mantén los secretos en el servidor y referéncialos mediante un identificador opaco dentro del token.
Depurar tokens de forma segura
En el día a día, el decodificador brilla a la hora de depurar flujos de autenticación: confirmar que el usuario correcto está en el claim de sujeto, comprobar que la audiencia coincide con el servicio que rechaza la petición, verificar que están presentes los scopes o roles, y leer la expiración para ver si un 401 no es más que un token caducado. Copiar el encabezado o el payload formateado en un informe de error o en un fixture de prueba es cuestión de un clic.
Todo ocurre localmente en tu navegador —el token y cualquier secreto que escribas nunca se suben, registran ni almacenan—, así que es seguro inspeccionar tokens de producción reales. Dicho esto, trata los tokens como las credenciales que son: un token válido y no caducado es una llave activa a una cuenta, así que evita pegarlo en herramientas poco fiables y, al compartir ejemplos, prefiere tokens caducados o de prueba.
Preguntas frecuentes
¿Qué es un JSON Web Token (JWT)?
¿Decodificar un JWT revela la contraseña o el secreto?
¿Cómo funciona aquí la verificación de la firma?
¿Qué significan los claims exp e iat?
¿Se envía mi token a un servidor?
Herramientas relacionadas
Sigue trabajando con estas prácticas herramientas