Cómo descodificar un JWT

Pega el token en un decodificador que se ejecute en tu navegador, nunca en uno que pida una subida; lee la cabecera y el payload, comprueba exp contra la hora actual y trata alg:none como una alarma. Descodificar es leer, no verificar — solo la clave del emisor prueba que un token es genuino. Todos los pasos de abajo ocurren en local, en el decodificador de JWT del sitio.

Solo local

¿Solo quieres la herramienta? Abre Decodificar JWTDecodifica un token y mira qué significa cada claimAbrir herramienta

Un JSON Web Token parece papel pintado — tres segmentos base64 unidos por puntos — y ese disfraz es exactamente la razón por la que descodificarlo a propósito, en lugar de entrecerrar los ojos ante él, merece un procedimiento. Dentro hay una cabecera que nombra el algoritmo de firma, un payload que nombra a quién pertenece el token y cuándo muere, y una firma que (si es genuina) ata ambos a quien lo emitió. Los dos primeros los puede leer cualquiera; el tercero solo se puede comprobar con una clave.

Esta página es la versión segura de ese trabajo de lectura: cinco pasos, cada uno con su comprobación, todos ejecutados en tu propio navegador. La distinción importa porque un JWT es una credencial bearer — quien la tenga puede usarla. Pegar un token en vivo en una página web cualquiera que lo descodifica del lado del servidor es entregar esa credencial al dueño de la página; pegarlo en una herramienta que descodifica en local no se lo entrega a nadie, y el panel de red es cómo verificas esa afirmación en lugar de creerla.

Una expectativa que conviene fijar antes del primer paso: un decodificador puede decirte qué dice un token y marcar lo que parece incorrecto, pero no puede decirte que un token es genuino. La autenticidad es una cuestión de firma, y las cuestiones de firma necesitan la clave del emisor. El último paso va de dónde ocurre realmente esa verificación — y de por qué la respuesta normalmente no es esta página.

Los cinco pasos se ejecutan en el decodificador de JWT del sitio — pega, lee, y cada claim llega con su significado adjunto.

Para la anatomía completa de los tres segmentos, la guía de la estructura de un JWT explica cada parte con ejemplos reales antes de que inspecciones uno en vivo.

Los pasos

Copia solo el token — nada antes ni después
Desde el encabezado de la respuesta, la entrada del localStorage o la petición que estás inspeccionando, copia exactamente los tres segmentos base64: el trozo que empieza por eyJ y termina en el último carácter del tercer segmento separado por puntos. Quita cualquier prefijo Bearer, comillas y espacios en blanco — un decodificador puede tolerar parte de eso, pero pegar un token limpio hace que cada comprobación posterior no admita ambigüedad.
Comprueba: Lo que copiaste empieza por eyJ (el base64 de {" — la cabecera de todos los JWT lo hace) y no contiene espacios. Esa comprobación minúscula caza el fallo de pegado más común antes de que intervenga cualquier herramienta.
Pégalo en un decodificador que se ejecute en local
Abre el decodificador de JWT y pega. La cabecera y el payload se descodifican al instante, en la pestaña — no se sube nada, y el panel de red no mostrará ninguna petición que transporte el token. Este es el paso donde divergen la versión segura y la insegura de este procedimiento: un decodificador del lado del servidor ya ha visto tu token; uno local no, porque nunca sale de tu equipo.
Comprueba: Aparecen dos objetos JSON — la cabecera primero, el payload debajo — sin ningún error entre ellos. Si el decodificador informa de base64 no válido o de JSON roto, el token quedó truncado o estropeado al copiar; vuelve a copiarlo desde la fuente.
Lee la cabecera — el algoritmo fija el modelo de amenazas
El alg de la cabecera nombra cómo se firmó el token: HS256 significa un secreto compartido, RS256 o ES256 significa un par de claves del que solo el emisor tiene la mitad privada, y none significa sin firmar. La herramienta marca alg:none de forma estridente, porque un token sin firmar es una afirmación que cualquiera podría haber escrito — aceptar uno no es un error, es un fallo de política. Apunta el alg ahora; el paso cinco lo necesita.
Comprueba: La fila del alg muestra un algoritmo real (HS256, RS256 y ES256 son los tres comunes) y nunca none. Si muestra none, detente: el token no prueba nada sobre sí mismo, y quien lo emitió necesita enterarse.
Lee el payload — y comprueba exp contra la hora real
Los claims del payload son toda la historia del token: sub nombra a quién pertenece, iss nombra quién lo hizo, aud nombra quién puede aceptarlo, y exp es el momento en que muere — descodificado en una fecha y hora reales por la herramienta, no el 1735689600 que tendrías que convertir tú. La herramienta también levanta avisos: un token caducado, uno sin exp alguno, uno cuyo nbf queda en el futuro porque el reloj del emisor va adelantado.
Comprueba: La fila de exp muestra una fecha sobre la que puedes razonar — «caducó hace 4 horas» o «caduca en 11 minutos» — y la lista de avisos coincide con lo que ves. Un token sin exp merece sospecha: en el papel nunca caduca.
Verifica con el emisor — no con el decodificador
Descodificar no prueba nada sobre la autenticidad: el segmento de firma solo se puede comprobar contra una clave, y la clave pertenece al emisor. En la práctica, la verificación ocurre donde vive la clave — tu backend, una puerta de enlace de API, la librería de tu proveedor de identidad — no en una pestaña del navegador. Si estás depurando por qué un servicio rechazó un token, lleva los claims descodificados a ese servicio: un exp ya pasado, un aud que no coincide o un kid que la caché de claves no ha recogido explican la mayoría de los rechazos.
Comprueba: Puedes nombrar, para el token que tienes delante, quién debe verificarlo (el servicio que lo aceptó) y qué comprueba ese servicio (la firma contra la clave del emisor, más exp, nbf y aud). Si no puedes, la guía de la estructura de un JWT tiene la pieza que falta.

Descodificar y verificar son verbos distintos

Descodificar es base64 y parseo de JSON — leer. Verificar es una operación criptográfica — comprobar la firma contra una clave que solo tiene el emisor. Un decodificador que te enseñara una insignia verde de «válido» estaría mintiendo, porque nunca puede tener la clave privada del emisor, y hasta con algoritmos de clave pública la comprobación le corresponde al servicio que acepta el token, que sabe qué clave y qué audiencia aplican.

Por eso la herramienta nunca afirma validez y en cambio explica lo que ve: el algoritmo, los claims, la caducidad como fecha y los avisos que levantaría un lector cuidadoso. El lector que necesita un veredicto — la API que recibe el token — es la única parte con los materiales para darlo.

Los claims que vale la pena leer siempre

Cuatro claims registrados cargan con la mayor parte de la historia. exp: cuándo muere el token — la fila más útil de toda la página. sub: de quién va el token, normalmente un identificador de usuario o de servicio. iss y aud: quién lo emitió y quién puede aceptarlo — un token emitido para una API suele ser rechazado por otra, y el lado que rechaza no funciona mal: está leyendo aud correctamente.

Los claims personalizados (roles, scopes, identificadores de tenant) se colocan al lado y se descodifican igual, pero trátalos como claims, no como hechos: son tan fiables como la firma que hay detrás, que el decodificador no ha comprobado. iat (issued at) y nbf (not before) completan los claims de línea temporal y explican la clase de errores «token not yet valid», que casi siempre son desviaciones de reloj.

Lo que un decodificador puede marcar — y lo que solo el servidor puede saber

La capa de avisos caza lo que el payload admite a la cara: alg:none, un segmento de firma vacío, un exp en el pasado, un token sin exp alguno, un nbf en el futuro. Estos son los defectos visibles sin ninguna clave, y valen la pena leerlos incluso cuando el token «funciona» — un sistema que acepta un token caducado es un sistema que quieres conocer.

Lo que ninguna herramienta de navegador puede decirte: si la firma verifica de verdad, si el emisor sigue reconociendo esta sesión, si el token fue revocado. Esas respuestas viven detrás de la clave del emisor y de sus registros. La honestidad del decodificador es la frontera que traza entre leer un token y confiar en uno.

Dónde se esconden los tokens — y por qué eso aboga por descodificar en local

Los JWT se alojan en los encabezados Authorization, en el localStorage del navegador, en los fragmentos de URL tras redirecciones de inicio de sesión y en los logs de la aplicación — sitios que se copian con mucha más despreocupación que los archivos. Cada una de esas copias es una credencial en vivo hasta que caduca, y por eso el paso de descodificación de este procedimiento insiste en una herramienta local: las capturas de pantalla, los tickets y los mensajes de chat con payloads descodificados los puede leer cualquiera, pero el token en bruto no debería viajar a ningún sitio salvo a los servicios llamados a verificarlo.

Los hábitos prácticos se deducen: descodifica en local, censura antes de compartir (el payload en una captura suele bastar para depurar) y, cuando un token tenga que moverse para depurar, muévelo por el canal que el emisor consideraría aceptable — no un sitio de pegados público.

Preguntas frecuentes

¿Es seguro pegar mi JWT en este decodificador?

Sí, porque la descodificación ocurre en tu navegador — el token lo parsea código local y nunca se transmite a ninguna parte. No tienes que creerlo a ciegas: abre DevTools, abre el panel de red, pega un token y observa que ninguna petición lo transporta. La Content-Security-Policy del sitio prohíbe las conexiones salientes por construcción, así que ni un bug podría filtrarlo.

¿Puede la descodificación decirme si un token es válido?

No, y un decodificador que afirme lo contrario te está engañando. La validez es una cuestión de firma — el token debe comprobarse contra la clave del emisor, más las políticas de exp, nbf y aud del servicio que lo recibe. Un decodificador te enseña lo que dice el token y marca los defectos de superficie (caducado, sin firmar, sin exp); el veredicto pertenece al verificador que tiene la clave.

¿Qué significa alg:none y por qué es peligroso?

Significa que la cabecera no declara ningún algoritmo de firma — el segmento de firma debería estar vacío, y el contenido del token es una afirmación que cualquiera podría haber escrito. Algoritmos como HS256 existen precisamente para que la manipulación sea detectable; alg:none elimina esa garantía. Un decodificador lo marca de forma estridente porque aceptar un token así es una clase de vulnerabilidad conocida, no una manía de formato.

¿Por qué mi token aparece como caducado cuando la app sigue funcionando?

Porque la app lo refrescó. Los tokens de acceso de vida corta caducan a propósito y se canjean por otros nuevos en segundo plano, normalmente con un refresh token; lo que copiaste probablemente era ya una generación retirada. Descodifica el token que la app está enviando ahora y su exp debería estar en el futuro — si no lo está, el servicio que lo acepta no está comprobando la caducidad, y eso conviene saberlo.

¿En qué se miden exp, iat y nbf?

En segundos desde el 1 de enero de 1970 UTC — la hora Unix — y por eso un payload en bruto los muestra como números de diez dígitos como 1735689600. El decodificador convierte cada uno en una fecha y hora reales y expresa la relación con el presente («caducó hace 4 horas», «caduca en 11 minutos»), que es la forma en que una persona puede actuar de verdad.

¿Puedo compartir una captura de un token descodificado?

La cabecera y el payload descodificados suelen estar bien — son legibles por diseño y una captura que muestra claims es así como se depura la mayoría de las veces. Lo que nunca debe compartirse es el token en bruto: es una credencial bearer, y quien la tenga puede usarla hasta que caduque. Censura los segmentos de firma y cualquier identificador que no pondrías en un ticket, y deja el token completo fuera de las capturas por completo.

Equipo de ToolsByUs · Cómo comprobamos nuestras herramientas