Decodificar JWT — Leer Cabecera y Payload
Decodifica un JWT para leer claramente su cabecera y payload, al instante y en privado en tu navegador.
El token se queda en tu equipo
Nada que borrar después
Hecho para credenciales vivas
Funciona en todo navegador moderno
Cómo funciona
- 1
Pega el token
Entero, con los dos puntos incluidos: las tres partes se separan con ellos.
- 2
Lee las reclamaciones
Cabecera a un lado, carga al otro, con las marcas de tiempo convertidas en fechas.
- 3
Comprueba a qué venías
Normalmente la caducidad, el emisor, la audiencia o a qué usuario pertenece el token.
Por qué usar esta herramienta
Cabecera y carga en paralelo
El algoritmo y la pista de clave junto a las reclamaciones, que es donde se responden casi todas las dudas.
Marcas de tiempo legibles
`exp`, `iat` y `nbf` mostradas como fechas y no como números de diez cifras que tengas que convertir.
Caducidad comprobada contra ahora
Ves de inmediato si el token sigue dentro de su ventana, sin hacer la cuenta.
Honesto sobre la verificación
Esto decodifica; no verifica una firma, y lo dice en vez de insinuar que el token es válido.
No se transmite nada
El token se analiza en tu navegador: una credencial de sesión en uso nunca llega a un servidor.
Gratis y sin cuenta
Sin registro, sin marca de agua y sin límite de cuántos tokens inspecciones.
Decodificar no es verificar, y la diferencia es todo el modelo de seguridad
Un JWT tiene tres partes separadas por puntos, y las dos primeras son simplemente texto base64url. Cualquiera que tenga el token puede leer la cabecera y la carga en un paso —es lo que hace esta página— y no hace falta ninguna clave, ningún permiso y ningún secreto. Verificar es una operación completamente distinta: recalcular la firma sobre las dos primeras partes con la clave del emisor y comprobar que coincide con la tercera. Solo la verificación te dice que el token es auténtico y no ha sido modificado. Un decodificador te dice qué afirma un token, nunca si la afirmación es cierta, porque cualquiera puede fabricar un token que diga lo que quiera. Si estás depurando, decodificar responde a tu pregunta. Si estás decidiendo si confiar en una petición, decodificar no responde absolutamente nada.
La carga la puede leer cualquiera, y eso se olvida constantemente
Esto se deduce de lo anterior y merece decirse aparte, porque es fuente de exposición real de datos. La carga de un JWT está codificada, no cifrada. Cada reclamación que contiene —el identificador de usuario, el correo, el rol, el inquilino, los campos internos que resultaron cómodos de incluir— es visible para cualquiera que tenga el token, incluido el navegador al que se emitió, cualquier extensión que corra en ese navegador y cualquiera que lo obtenga después. La firma protege la carga de ser modificada, no de ser leída. Así que un token es un lugar razonable para un identificador y un rol, y un mal lugar para una dirección, un teléfono, un estado de licencia que alguien podría encontrar embarazoso o cualquier otra cosa que no imprimirías en el exterior de un sobre. Si una reclamación debe seguir siendo privada, no pertenece al token.
Nunca dejes que el token te diga cómo verificarlo
Las vulnerabilidades de JWT más célebres comparten una misma forma: una biblioteca lee el campo `alg` de la cabecera y se fía de él. La versión histórica es `alg: none`, que declara el token sin firmar; un verificador que lo respete acepta cualquier cosa, y el atacante simplemente escribe su propia carga y quita la firma. La versión más sutil es la confusión de algoritmos: un token firmado con HMAC se presenta a un servidor que espera RSA, y si el código pasa la clave pública RSA como secreto HMAC, y esa clave pública está publicada, el atacante puede firmar tokens con ella. Ambas se arreglan igual: el código verificador decide qué algoritmo y qué clave acepta, y rechaza todo lo demás, en vez de leer la respuesta en la parte no confiable del token que está comprobando.
Las marcas de tiempo van en segundos, y nada las hace cumplir por sí solo
Tres reclamaciones controlan la ventana de validez. `exp` es la caducidad, `nbf` el momento antes del cual no debe aceptarse e `iat` cuándo se emitió. Las tres van en segundos desde la época Unix, lo que hace tropezar a quien trabaja en un lenguaje cuyas marcas nativas son milisegundos: el token resultante o está ya caducado o vale para los próximos cincuenta mil años, y ambos errores son suficientemente comunes como para comprobarlos primero. Lo más importante es que son reclamaciones, no cumplimiento. Nada del token deja de funcionar cuando pasa `exp`; la caducidad solo existe si el código verificador la compara con la hora actual y rechaza la petición. Un decodificador que te muestra un token caducado te dice qué pretendía el emisor, no qué hará con él un servidor concreto.
Un JWT no se puede revocar, y ese es el trato que aceptaste
La razón de usar estos tokens es la verificación sin estado: un servidor puede confirmar que una petición es auténtica usando solo una clave, sin consultar una base de datos, y eso es lo que los hace escalar entre servicios. La consecuencia directa es que no hay nada que borrar. Una sesión guardada en base de datos termina en cuanto eliminas la fila; un token firmado sigue siendo válido hasta caducar pase lo que pase en el emisor, porque nadie consulta al emisor. Un token filtrado es por tanto utilizable hasta que expire, y por eso mismo los tokens de acceso deben durar poco —minutos, no semanas— con un token de refresco de vida más larga que sí puede revocarse porque sí se comprueba contra almacenamiento. Si tus tokens de acceso duran un mes, tienes todos los inconvenientes de la ausencia de estado y ninguna de las garantías de una sesión.
Por qué este es el caso más claro para decodificar en local
Casi cualquier otra herramienta de texto maneja material que es sensible por las circunstancias. Un JWT es sensible por definición: es la credencial, y un token válido y no caducado basta para actuar como el usuario al que se emitió. Pegar uno en un decodificador alojado envía una credencial de autenticación en funcionamiento a un tercero, por un canal que no deja rastro, a cambio de leer campos que podrías haber leído en local. Si al token le quedan horas, quien lo reciba puede usarlo. Esta página analiza en el navegador y no transmite nada, y puedes comprobarlo en la pestaña Red de las herramientas de desarrollo. Y si alguna vez pegaste un token de producción en un sitio web para ver su caducidad, tratar ese token como comprometido es la respuesta correcta.
Errores comunes que conviene evitar
- Tomar una decodificación correcta por un token válido. Decodificar no necesita clave y no demuestra nada; solo verificar la firma con la clave del emisor establece que el token es auténtico.
- Poner datos privados en la carga. Está codificada, no cifrada: la firma impide que se modifique, no que se lea, así que cualquiera con el token ve todas las reclamaciones.
- Dejar que el token elija su algoritmo de verificación. Leer `alg` de la cabecera es como funcionan los ataques `alg: none` y de confusión de algoritmos; el verificador debe fijar algoritmo y clave por adelantado.
- Escribir `exp` en milisegundos. Las marcas de un JWT van en segundos desde la época, así que un valor en milisegundos da un token válido decenas de miles de años, o uno ya caducado.
- Pegar un token de producción en un decodificador alojado. Es una credencial viva, el pegado no deja rastro y quien lo reciba puede usarlo hasta que caduque.
Comparativa
| Aspecto | Esta herramienta | Decodificadores online | Una llamada de biblioteca |
|---|---|---|---|
| Token enviado a un servidor | Nunca | Normalmente sí | No |
| Marcas de tiempo como fechas | Sí | A veces | Las formateas tú |
| Deja claro que no verifica | Sí | A menudo confuso | Explícito en la API |
| Funciona sin abrir un proyecto | Sí | Sí | No |
| Cuenta o registro | No hace falta | A menudo exigido | No hace falta |
| Precio | Gratis | Gratis / planes de pago | Gratis |
Características
Análisis completo de las tres partes
Cabecera, carga y segmento de firma mostrados por separado como los define el formato.
base64url tratado bien
Los JWT usan el alfabeto seguro para URL sin relleno, algo que un decodificador Base64 normal falla.
Reclamaciones estándar etiquetadas
`iss`, `sub`, `aud`, `exp`, `nbf`, `iat` y `jti` con nombre y no dejadas como abreviaturas.
Tokens malformados señalados
Un segmento ausente o una codificación inválida se informa en vez de producir un sinsentido parcial.
Unicode en las reclamaciones
Nombres y valores en árabe, turco o cualquier escritura se decodifican intactos.
Instantáneo, sin petición
El análisis ocurre al pegar, sin descargar nada y sin enviar nada.
Nada que instalar
Sin biblioteca, sin entorno de ejecución, sin dependencias: funciona en la página web.
Listo para árabe y RTL
Interfaz completa en ocho idiomas, incluido el árabe de derecha a izquierda.
Seguro por defecto
Servido por HTTPS, sin rastreo de contenido ni subida a terceros.
Quién la usa
Desarrolladores
Ver por qué se rechaza una llamada de API: casi siempre un token caducado o la audiencia equivocada.
Ingenieros de seguridad
Inspeccionar las reclamaciones y el algoritmo de un token hallado en un log o un informe de fallo.
Integradores de API
Confirmar qué ámbitos y roles emitió realmente un proveedor antes de escribir contra ellos.
Ingenieros de soporte
Leer un token enviado por un cliente para ver a qué cuenta e inquilino pertenece.
Preguntas Frecuentes
No. Todo se ejecuta localmente en tu navegador — tu texto nunca se sube, guarda ni comparte.
Sí — totalmente gratis, sin cuenta y sin límites.