Saltar al contenido principal
ToolsByUs

Decodificar JWT

El descodificador de JWT lee la cabecera y el payload de un JSON Web Token en tu navegador y explica lo que encuentra: el algoritmo de firma, cada claim con su significado y la expiración descodificada como fecha real. Nunca verifica la firma, porque eso exigiría enviar tu token a quien posea la clave.

Solo local
JSON Web Token
0 B1 líneaLín. 1, Col. 1
No hay nada que decodificar. Pega un token arriba. No se sube nada: se decodifica en esta pestaña.

¿Cómo funciona Decodificar JWT?

Un JSON Web Token son tres segmentos codificados en base64url unidos por puntos: header.payload.signature. Los dos primeros son objetos JSON y no están cifrados — base64url es una codificación, no un cifrado. Cualquiera que tenga el token puede leer todos sus claims, y por eso meter una contraseña, un número de tarjeta o un ID interno de base de datos en el payload de un JWT es un error que la gente comete con regularidad y descubre tarde.

Descodificar es, por tanto, directo: separar por los puntos, descodificar en base64url los dos primeros segmentos y parsear cada uno como JSON. El cuidado está en los detalles que rompen a los descodificadores ingenuos. Los segmentos JWT son base64url sin relleno (RFC 7515 §2), así que un descodificador que exija el relleno con = rechaza la mayoría de los tokens reales. El alfabeto usa - y _ en lugar de + y /, así que un descodificador Base64 estándar falla en aproximadamente la mitad de los tokens, según lo que hayan codificado los bytes aleatorios.

Lo que esta herramienta añade más allá de descodificar es interpretación. Los claims registrados de RFC 7519 van anotados con su significado. exp, nbf e iat son NumericDates — segundos desde el epoch de Unix — así que se muestran como una marca de tiempo real y un tiempo relativo, porque “1757546000” no es algo con lo que puedas actuar y “caducó hace 4 horas” sí.

Luego busca los problemas concretos que causan incidentes: un alg con valor none, un segmento de firma vacío, un token sin exp, un token aún no válido porque el reloj del emisor va adelantado, o un aud ausente que permite reenviar el token contra otro servicio que confíe en el mismo emisor.

Se queda deliberadamente antes de la verificación. Comprobar una firma requiere el secreto o la clave pública del emisor, y la única forma de que una página web consiga una es enviando tu token a algún sitio. Ofrecer eso destruiría la única propiedad que hace seguro pegar una credencial real en esta página.

Segmento del token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
  .eyJzdWIiOiJ1c3JfOGYyYTFiIiwiZXhwIjoxNzU3NTQ2MDAwfQ
  .3Zc0Kz1qHhVQ9oFmR2sT7xYbN4dJwEuLpAiCgXvKmO8

Descodificado

header  { "alg": "HS256", "typ": "JWT" }
payload { "sub": "usr_8f2a1b", "exp": 1757546000 }

exp  2026-09-10 21:53:20 UTC  (expired)
sub  Subject — who the token is about

¿Qué opciones y casos límite admite Decodificar JWT?

Referencia técnica y opciones
ParámetroTipoValor predeterminadoComportamiento y casos límite
algstringobligatorioAlgoritmo de firma, en la cabecera. HS* es HMAC con un secreto compartido; RS*/PS* son RSA; ES* es ECDSA; EdDSA es Ed25519. Un valor de "none" se marca como error: una biblioteca que confía en el alg del propio token permite que cualquiera lo falsifique.
typ / kidstringopcionaltyp es convencionalmente "JWT". kid identifica qué clave firmó el token y es lo que permite a un emisor rotar claves sin invalidar todo a la vez.
expNumericDateopcionalSegundos desde la época Unix, no milisegundos ni una cadena ISO. Se decodifica aquí a una marca de tiempo UTC y un tiempo relativo. Un token sin exp nunca expira por sí solo y solo puede ser detenido mediante revocación.
nbfNumericDateopcionalNot-before (No válido antes). Un token que aún no es válido es casi siempre un desfase horario entre el servidor emisor y la máquina que lo lee, en lugar de un retraso deliberado.
audstring | string[]opcionalDestinatario previsto. Un servicio debe rechazar un token cuya audiencia no sea él mismo; sin aud, un token creado para un servicio puede ser reutilizado en otro que confíe en el mismo emisor.
Codificación del segmentobase64urlsin rellenoRFC 7515 §2 utiliza el alfabeto seguro para URL (- y _) con el relleno eliminado. Los decodificadores Base64 estándar fallan en cuyos bytes producen + o /, por lo que a veces un token se decodifica en una herramienta y no en otra.
Firmabase64urlno verificadaSe muestra pero nunca se verifica. La verificación requiere la clave del emisor; obtener una implicaría transmitir tu token. Un segmento de firma vacío se marca, ya que significa que no hay protección de integridad en absoluto.
Tamaño de entradabytes8 MBEl límite principal del subproceso compartido en todo el sitio. Los tokens reales tienen unos pocos kilobytes; el límite existe para que pegar la cosa incorrecta no pueda bloquear la pestaña.

Preguntas frecuentes

¿Es seguro pegar un JWT real en esta página?

La descodificación ocurre por completo en tu navegador y el token nunca se transmite — abre DevTools, cambia al panel «Network», pega un token y no verás ninguna petición que lo lleve. Eso hace esta página categóricamente más segura que un descodificador que envía a un servidor, donde tu token acabaría en un access log. La advertencia restante no va de este sitio: cualquier credencial que pegues en cualquier navegador de una máquina que no controlas debe rotarse después.

¿Por qué no puede verificar la firma?

Porque verificar necesita la clave. En HS256 es el secreto compartido; en RS256, la clave pública del emisor, que normalmente se obtiene de un endpoint JWKS. Una página del navegador solo podría hacer cualquiera de las dos cosas enviando tu token, o el secreto, a algún sitio — lo que destruiría la propiedad que hace segura esta página. La verificación pertenece a tu servicio, donde la clave ya vive.

Mi token se descodifica aquí, pero mi biblioteca lo rechaza. ¿Por qué?

Descodificar y aceptar son preguntas distintas. Las causas más comunes son: el token expiró (mira la fila exp — esta herramienta la muestra como fecha real); la audiencia no coincide con lo que tu servicio espera; el nbf está en el futuro porque el reloj del servidor emisor va adelantado; o la firma no verifica con la clave con la que está configurado tu servicio, a menudo porque el emisor rotó las claves y el kid apunta ahora a una que tu caché aún no recogió.

¿Qué significa alg: none y por qué se marca como error?

Significa que el token no está firmado. El peligro no es el valor en sí, sino lo que un verificador haga con él: algunas bibliotecas JWT leían históricamente alg del token y elegían el método de verificación en consecuencia, así que un atacante podía tomar un token válido, cambiar el algoritmo a none, quitar la firma y lograr que se aceptara. Un verificador correcto decide el algoritmo esperado a partir de su propia configuración e ignora lo que el token diga.

¿Un JWT está cifrado?

No. Un JWT estándar (un JWS) está firmado, no cifrado — la firma prueba que el payload no se ha alterado y no hace nada por ocultarlo. Cada claim es legible para cualquiera que tenga el token, que es exactamente lo que esta página demuestra. Si necesitas ocultar el contenido, lo que quieres es un JWE, que tiene cinco segmentos en lugar de tres y no puede leerse sin la clave de descifrado.

¿Puedo descodificar un token que ya expiró?

Sí. La expiración es un claim dentro del payload, no una propiedad de la codificación, así que un token expirado se descodifica igual que uno vigente. Esta herramienta lo lee y te dice cuándo expiró y hace cuánto, que suele ser la forma más rápida de confirmar que un 401 intermitente es un problema de vida del token y no de permisos.

¿Qué más puede hacer Decodificar JWT?

Equipo de ToolsByUs · Cómo comprobamos nuestras herramientas