Decodificador JWT
Decodifica e inspecciona tokens JWT online. Ve el encabezado, las cargas útiles y el estado de expiración al instante. Decodificador JWT gratuito — sin datos enviados a servidores.
This tool decodes the header and payload. Signature verification requires the secret key and is not performed — never paste tokens from production systems into online tools.
¿Qué es un JWT?
Un decodificador de JWT es una herramienta que toma un JSON Web Token y lo separa en sus tres componentes para que puedas leer e inspeccionar directamente los datos que transporta. Los JSON Web Tokens, estandarizados en el RFC 7519 y conocidos por sus siglas JWT (pronunciado "jot" en inglés), son un formato compacto y apto para URLs que permite representar declaraciones entre dos partes de forma firmada criptográficamente. Hoy en día son el mecanismo predominante para la autenticación sin estado en aplicaciones web modernas y APIs REST, y los utilizan proveedores de identidad como Auth0, Okta, Firebase Authentication, AWS Cognito y miles de implementaciones personalizadas en proyectos de todo tipo y tamaño. Todo JWT está compuesto por tres segmentos codificados en Base64URL y separados por puntos. Base64URL es una variante del estándar Base64 definida en el RFC 4648 que sustituye los caracteres + y / por - y _ respectivamente, y omite el relleno de signos de igual, haciendo que la cadena resultante sea segura para incluirla directamente en URLs y cabeceras HTTP sin necesidad de codificación adicional. El primer segmento es el encabezado (header), un objeto JSON que normalmente contiene dos campos: alg, el algoritmo de firma empleado (como HS256, RS256 o ES256), y typ, el tipo de token, que casi siempre es la cadena "JWT". El segundo segmento es el payload o carga útil, el núcleo del token, que contiene un conjunto de declaraciones llamadas claims. Los claims son afirmaciones sobre una entidad, generalmente el usuario autenticado, junto con metadatos adicionales sobre el contexto de la sesión. Los claims reservados definidos por el estándar incluyen iss (emisor), sub (sujeto, normalmente el ID del usuario), aud (audiencia), exp (tiempo de expiración), nbf (no válido antes de), iat (emitido en) y jti (ID del JWT). Las aplicaciones pueden añadir cualquier cantidad de claims personalizados junto a estos campos estándar para transmitir información específica del negocio. El tercer segmento es la firma criptográfica, que sirve para verificar que el encabezado y el payload no han sido alterados, aunque esta herramienta no realiza esa verificación ya que requiere la clave secreta o el certificado público en posesión del servidor emisor. El claim de expiración, almacenado en el campo exp, es una marca temporal POSIX: el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC. Esta herramienta decodifica ese valor numérico, lo compara con la hora actual del sistema en tu navegador y determina si el token sigue siendo válido o ya ha caducado, mostrando la fecha exacta de expiración y una cuenta regresiva del tiempo restante sin que tengas que hacer ningún cálculo manual.
Cómo Usar el Decodificador JWT
Usar el decodificador de JWT es muy sencillo: copia el token de donde se encuentre — la consola de desarrollador del navegador, una respuesta HTTP capturada con Postman o Insomnia, una petición en las herramientas de red, un archivo de variables de entorno o una cookie de autenticación — y pégalo en el campo de entrada situado en la parte superior de la página. La herramienta acepta el formato completo de tres partes separadas por puntos (xxxxx.yyyyy.zzzzz) que utiliza todo JWT estándar. En cuanto detecta una estructura de token válida, la procesa de forma instantánea en tu navegador sin necesidad de pulsar ningún botón, dividiendo la cadena en cada punto y aplicando la decodificación Base64URL de forma independiente al primer y al segundo segmento. El resultado decodificado se presenta en dos paneles diferenciados. El panel de encabezado (Header) muestra el objeto JSON del primer segmento, formateado con sangría correcta para que cada par clave-valor sea fácil de identificar de un vistazo. Normalmente verás el campo alg revelando el algoritmo de firma — por ejemplo HS256 para HMAC con SHA-256, RS256 para RSA con SHA-256, o ES256 para ECDSA con curva elíptica — junto al campo typ que confirma el tipo de token. El panel de payload muestra los claims del segundo segmento, también formateados como JSON con sangría. En tokens emitidos por proveedores OAuth 2.0 u OpenID Connect, encontrarás el sujeto (sub), el emisor (iss), la audiencia (aud) y los claims de tiempo todos reunidos en un mismo lugar, junto a cualquier claim personalizado que añada tu aplicación. Junto a los paneles de decodificación, la herramienta incluye un indicador de estado de expiración. Lee el claim exp, convierte la marca temporal POSIX a una fecha y hora legible en tu zona horaria local, y determina si el momento actual es anterior o posterior a ese instante. Si el token sigue activo, verás una confirmación con la fecha exacta de caducidad y una cuenta regresiva mostrando cuánto tiempo le queda. Si ya ha caducado, la herramienta indica la fecha y hora en que dejó de ser válido y cuánto tiempo hace de eso, lo cual resulta especialmente útil cuando una sesión se comporta de forma inesperada y necesitas saber rápidamente si la caducidad del token es la causa del problema. Cada panel de salida incluye un botón de copia que coloca el contenido JSON formateado en el portapapeles con un solo clic. Si la cadena introducida no tiene la estructura válida de un JWT — por ejemplo, si le falta alguno de los tres segmentos o contiene caracteres fuera del alfabeto Base64URL — la herramienta muestra un mensaje de error claro describiendo el problema, para que puedas identificar rápidamente un token malformado o truncado. Un consejo práctico: si copias el token desde la pestaña de red del navegador, asegúrate de copiar únicamente el valor del token y no el prefijo "Bearer " que suele precederlo en la cabecera Authorization, ya que la herramienta espera exclusivamente la cadena de tres partes sin ese prefijo.
¿Por Qué Usar un Decodificador JWT?
El decodificador de JWT resuelve un problema recurrente y real para cualquier persona que trabaje con sistemas de autenticación modernos: los JWT transportan datos que están codificados pero no cifrados, y leerlos manualmente es tedioso y propenso a errores. La decodificación Base64URL es simple en teoría, pero hacerla a mano — o escribir un script de un solo uso en Node.js, Python o Bash — cada vez que necesitas inspeccionar un token durante el desarrollo o la resolución de problemas lleva tiempo e introduce fricción innecesaria en el flujo de trabajo. Un decodificador dedicado en el navegador elimina esa fricción por completo, ofreciendo una salida instantánea, formateada y legible en el momento en que pegas el token, sin instalaciones, sin dependencias y sin configuración previa. La privacidad y la seguridad son razones fundamentales para usar una herramienta que procesa todo localmente en el navegador en lugar de enviar los datos a un servidor externo. Los JWT frecuentemente contienen información sensible: IDs de usuario, direcciones de correo electrónico, roles asignados, alcances de permisos, identificadores organizativos y, en algunos sistemas, incluso membresías en grupos de seguridad o detalles del plan de suscripción del usuario. Pegar ese tipo de token en un servicio en línea que lo procesa en el servidor significa transmitir esa información a un tercero desconocido. Dado que el decodificador de JWT de Yanapex realiza toda la decodificación de forma local dentro de tu navegador usando JavaScript estándar, ningún dato abandona tu dispositivo. Esto es especialmente importante cuando se trabaja con tokens de entornos de producción, donde los claims reflejan datos reales de personas sujetos a normativas de privacidad como el RGPD en Europa, la Ley de Protección de Datos Personales en distintos países de América Latina o normativas sectoriales equivalentes. Desde el punto de vista del desarrollo, la comprobación automática de expiración ahorra una cantidad desproporcionada de tiempo de depuración. Un token que parece sintácticamente correcto pero que ya ha caducado provocará una respuesta 401 No Autorizado en una API, y sin una forma rápida de verificar el valor de exp, un desarrollador podría invertir un tiempo valioso investigando configuraciones de red, lógica de middleware o el formato de las cabeceras antes de descubrir que la causa raíz es simplemente que el token ha expirado. Mostrar el estado de expiración de forma inmediata acorta los ciclos de depuración y redirige la atención hacia el problema real con mucha mayor rapidez. Los estudiantes y desarrolladores que se están iniciando en el ecosistema JWT también se benefician enormemente de ver la salida decodificada. Leer el token en crudo no transmite ninguna intuición sobre lo que contiene; ver el encabezado y el payload decodificados en paralelo, con los nombres de campo y valores claramente mostrados como JSON formateado, hace concreto el concepto abstracto de los claims y facilita el aprendizaje. El campo alg muestra directamente qué algoritmo criptográfico está en uso, fomentando la conciencia sobre las implicaciones de seguridad de algoritmos más débiles como HS256 con secretos cortos frente a esquemas asimétricos más robustos como RS256 o ES256.
Casos de Uso Comunes
Un desarrollador de back-end que construye una API REST con Node.js y Express ha configurado un middleware de autenticación basado en JWT. Durante las pruebas de integración, un colega del front-end reporta que ciertos endpoints protegidos devuelven errores 401 de forma inesperada. El desarrollador pega el token que el front-end está enviando en el decodificador, ve de inmediato que el claim exp corresponde a un instante doce minutos en el pasado y se da cuenta de que la lógica de refresco de token en el código del cliente tiene un error que impide que el nuevo token se almacene correctamente después de obtenerlo. Un ingeniero de seguridad que realiza una auditoría interna del sistema de autenticación de una empresa necesita verificar que los tokens emitidos por el proveedor de identidad contienen los claims correctos de audiencia (aud) y emisor (iss) antes de que la API los acepte. En lugar de escribir un script desechable, el ingeniero decodifica varios tokens de muestra de diferentes entornos y compara los valores de los claims, confirmando que los tokens del entorno de staging no pueden reutilizarse contra la API de producción porque el campo de audiencia difiere entre ambos entornos. Un desarrollador junior que está aprendiendo sobre OAuth 2.0 y OpenID Connect sigue un tutorial que usa Google Sign-In. Tras completar el flujo de inicio de sesión, el tutorial le indica que registre el ID token en la consola del navegador. El estudiante copia el token y lo pega en el decodificador, viendo por primera vez los campos email, name, picture, sub e iss en el payload, lo que hace que el flujo abstracto de OAuth se vuelva de repente tangible y comprensible de una manera que la lectura de la especificación por sí sola no logra. Un desarrollador de aplicaciones móviles que usa Firebase Authentication está construyendo una funcionalidad que se comporta de forma distinta según si el usuario tiene una suscripción premium. El desarrollador ha configurado claims personalizados en Firebase a través de Cloud Functions. Para verificar que los claims se están estableciendo correctamente después de que un usuario mejora su plan, decodifica el ID token de Firebase para ese usuario a partir de los registros de depuración de la aplicación y confirma que el campo personalizado premiumUser: true está presente en el payload antes de publicar la funcionalidad. Un ingeniero de QA que escribe pruebas de extremo a extremo para una plataforma SaaS necesita parametrizar los casos de prueba con tokens que lleven roles específicos. Para entender los nombres exactos de los claims y los valores que espera la API, el ingeniero decodifica tokens generados para distintos usuarios de prueba — administrador, solo lectura, gestor de facturación — y anota la estructura, usando esa información para construir fixtures de prueba precisos que ejerciten correctamente la lógica de autorización. Un ingeniero de DevOps que investiga un fallo de autenticación en un clúster de Kubernetes observa que las llamadas entre servicios están siendo rechazadas sistemáticamente. El ingeniero extrae el JWT de cuenta de servicio del secreto montado en el pod, lo pega en el decodificador y descubre que el token fue emitido con una ventana nbf (no válido antes de) muy ajustada y que el reloj del sistema del clúster presenta una ligera desviación, lo que hace que el servicio receptor considere que el token todavía no es válido aunque acaba de ser emitido. Un especialista de soporte técnico en una empresa SaaS recibe un ticket de un cliente que afirma que no puede acceder a una funcionalidad específica a pesar de haber actualizado su plan de suscripción. El especialista le pide al cliente que abra la consola de desarrollador del navegador, copie su token de sesión y lo pegue en el decodificador durante una sesión de pantalla compartida. El especialista ve de inmediato que el claim de plan en el payload sigue reflejando el nivel anterior, lo que indica un problema de caché o un retraso en el aprovisionamiento del sistema de cuentas, y no un error de interfaz como el cliente suponía. Un desarrollador freelance que integra un proveedor de identidad externo en la aplicación de comercio electrónico de un cliente necesita verificar que los tokens devueltos tras el inicio de sesión contienen los claims personalizados store_id y locale correctos antes de que la aplicación renderice la tienda personalizada. Al decodificar un token de muestra devuelto por el entorno de sandbox del proveedor, el desarrollador confirma que todos los valores esperados están presentes y correctamente formateados antes de configurar el entorno de producción.