Pega un JSON Web Token para ver su cabecera, su carga útil y cada claim en lenguaje claro, con la expiración comprobada según tu propio reloj. Después verifica la firma con un secreto o una clave pública, sin que el token salga nunca de esta pestaña.
Pégalo tal como llegó: con o sin Bearer, entre comillas o partido en varias líneas. Se decodifica en esta pestaña mientras escribes.
El ejemplo está firmado con HS256, es válido durante una hora desde el momento en que lo cargas y su secreto se rellena en el verificador de abajo.
Cada segmento está etiquetado y coloreado. La cabecera y la carga útil son JSON en base64url; la firma son bytes sin procesar.
Un JWT son tres segmentos base64url unidos por puntos: cabecera, carga útil y firma. Pega uno y cada segmento se marcará aquí.
Pega un token, o carga el ejemplo, y aquí aparecerán su estructura, su expiración y su algoritmo.
Qué algoritmo firmó el token y con qué clave. Decodificada desde base64url.
Aquí aparece la cabecera decodificada, con cada uno de sus parámetros explicado.
Los claims. Codificados, no cifrados: cualquiera que tenga el token puede leerlos.
Aquí aparece la carga útil decodificada como JSON formateado, lista para copiar.
Claims registrados de la RFC 7519, claims habituales de OpenID Connect y OAuth, y cualquier claim personalizado. Las fechas se muestran en UTC, en tu propia zona horaria y en relación con el momento actual.
Cada claim de la carga útil aparece aquí con su significado, y exp, nbf e iat se convierten en fechas legibles.
Decodificar muestra lo que dice un token. Solo una firma comprobada con la clave correcta muestra quién lo dijo y que nada ha cambiado. La clave se queda en esta pestaña.
Decodifica arriba un token firmado y aquí aparecerá el campo de clave correspondiente: un secreto para HS256, HS384 y HS512, o una clave pública para RS, PS, ES y EdDSA.
Cualquiera puede escribir un token que se decodifique en los claims que quiera. Solo una firma comprobada con la clave del emisor, seguida de las comprobaciones de exp, nbf, iss y aud, hace que un token sea fiable. Nunca tomes una decisión de acceso basándote solo en una carga útil decodificada.
Abre las herramientas para desarrolladores de tu navegador (F12, o Cmd+Option+I en un Mac), elige la pestaña Red, pega un token y verifícalo. Ninguna petición lo lleva: la decodificación es JavaScript puro y la verificación es la API Web Crypto de tu navegador. La analítica de páginas vistas del sitio nunca incluye lo que escribes en un campo.
Un token con cinco segmentos es un JWE. Su cabecera protegida es legible y se muestra arriba, pero los claims están cifrados con una clave que solo tiene el destinatario. Ningún decodificador puede leerlos sin esa clave, y esta página no lo intenta.
Todo aquí se ejecuta en esta pestaña. El token, el secreto y la clave pública solo viven en la memoria de la página: nunca se guardan ni se envían, y desaparecen cuando los borras o cierras la página. La entrada se lee hasta 100,000 caracteres y las claves hasta 50,000. Las horas se comparan con el reloj de este dispositivo sin ningún margen, así que cerca de exp o nbf unos segundos de desfase entre tú y el emisor pueden cambiar el veredicto.
Cada segmento de un JWT es base64url. Decodifica uno a mano, o codifica una cabecera o una carga útil de prueba, con el alfabeto seguro para URL activado.
exp, iat y nbf son segundos Unix. Convierte cualquier marca de tiempo en una fecha, o una fecha en el número que debería llevar un token.
HS256 es un HMAC sobre SHA-256. Calcula HMAC y resúmenes SHA de cualquier texto para ver la primitiva que hay debajo de la firma.
Un JWT compacto tiene la forma header.payload.signature, con cada parte codificada en base64url. Las dos primeras son JSON que cualquiera puede decodificar sin clave, que es lo que hace esta página mientras escribes. La tercera es una firma sobre las dos primeras, y solo comprobarla con la clave correcta te dice que el token es auténtico y no ha cambiado. Todo se ejecuta en esta pestaña: el decodificador es JavaScript puro y la verificación usa la API Web Crypto integrada en tu navegador.
Cópialo de una cabecera Authorization, una cookie, una línea de registro o el depurador de tu proveedor de identidad. El Bearer inicial, las comillas que lo rodean y los saltos de línea se eliminan automáticamente, y los tres segmentos se etiquetan para que veas dónde termina la cabecera y dónde empieza la carga útil.
Los dos segmentos JSON se decodifican y se formatean. Cada claim registrado y los habituales de OpenID Connect y OAuth se explican con palabras sencillas, y exp, nbf, iat y auth_time se muestran en UTC, en tu propia zona horaria y como cuenta atrás en directo, así que un token expirado se ve de un vistazo.
Decodificar no prueba nada sobre quién creó un token. Pega el secreto HMAC para HS256, HS384 o HS512, o la clave pública del emisor como bloque PEM, como JWK o como un conjunto JWK completo para RS, PS, ES y EdDSA, y Web Crypto la comprueba en esta pestaña.
exp, nbf e iat se convierten en fechas legibles y en una cuenta atrás en directo, con un veredicto claro: no expirado, expirado, todavía no válido o sin expiración. Una marca de tiempo de 13 dígitos escrita en milisegundos por error se detecta y se explica, igual que un iat fijado en el futuro.
iss, sub, aud, exp, nbf, iat y jti de la RFC 7519, además de name, email, azp, nonce, auth_time, scope, client_id y otros claims habituales de OpenID Connect y OAuth, cada uno con su significado y la especificación de la que procede. Los claims personalizados se marcan como personalizados en lugar de adivinar qué son.
alg none, una firma ausente, parámetros de cabecera que apuntan a las propias claves del token (jku, x5u, jwk), relleno Base64 que las bibliotecas estrictas rechazan y secretos HMAC más cortos de lo que permite la RFC 7518: todo se señala, junto con lo que debes hacer al respecto.
HS256, HS384 y HS512 con un secreto compartido; de RS256 a RS512, de PS256 a PS512, de ES256 a ES512 y EdDSA con Ed25519 usando un PEM SPKI, un JWK o un conjunto JWK en el que la clave se elige por kid. Si el tipo de clave y el algoritmo no coinciden, se rechaza indicando cuál falla.
Un número incorrecto de segmentos, un carácter fuera del alfabeto base64url (con su posición exacta), un texto que no es JSON y una cabecera que no es un objeto reciben cada uno su propia explicación. Un JWE de cinco segmentos se reconoce como cifrado y su cabecera se sigue mostrando.
La decodificación es JavaScript puro y la verificación es la API Web Crypto de tu navegador. No hay subida, ni almacenamiento, ni ninguna petición que lleve el token, algo que puedes confirmar en la pestaña Red de las herramientas para desarrolladores de tu navegador.
Un JSON Web Token (RFC 7519) es una forma compacta de pasar claims entre dos partes: tres segmentos base64url unidos por puntos. La cabecera indica el algoritmo, la carga útil contiene los claims (de quién trata el token, quién lo emitió, para quién es y cuándo expira) y la firma permite al receptor comprobar que las dos primeras partes las produjo alguien con la clave correcta y que no se han modificado. Los JWT se usan sobre todo como tokens de acceso OAuth y como tokens de ID de OpenID Connect.
Divídelo por los puntos, decodifica en base64url los dos primeros segmentos y analiza cada resultado como JSON. Eso es todo lo que es decodificar, y por eso no hace falta ninguna clave. Pega un token en el cuadro de arriba y ocurre mientras escribes. base64url es Base64 normal con guion y guion bajo en lugar de más y barra, y sin los signos igual del final, así que en un decodificador Base64 estándar primero hay que volver a cambiar esos dos caracteres.
Solo en una página que lo decodifique localmente. Un JWT es una credencial al portador: quien tenga uno sin expirar normalmente puede usarlo. Esta página decodifica y verifica en tu navegador y nunca envía el token a ninguna parte, y puedes comprobarlo tú mismo abriendo la pestaña Red de las herramientas para desarrolladores de tu navegador antes de pegarlo. Aun así, usa tokens expirados o de prueba cuando puedas, y nunca pegues un secreto de firma de producción ni una clave privada en un sitio que no puedas inspeccionar.
Sí. Un JWT firmado está codificado, no cifrado. base64url es una codificación de texto reversible y sin clave, así que cualquiera que vea el token puede leer todos sus claims. Nunca pongas en la carga útil de un JWT contraseñas, claves de API ni datos personales que no le mostrarías a cualquiera que tenga el token. Si los claims deben seguir siendo privados, el token tiene que ser un JWE, que está cifrado.
Son valores NumericDate: segundos enteros o fraccionarios desde 1970-01-01 00:00:00 UTC, no milisegundos. exp es el momento a partir del cual el token debe rechazarse, nbf el momento antes del cual debe rechazarse e iat el momento en que se emitió. Por ejemplo, exp 1767225600 es 2026-01-01 00:00:00 UTC. Muchos verificadores admiten un pequeño desfase de reloj, normalmente de entre cero y cinco minutos. Un valor de 13 dígitos es casi siempre una marca de tiempo en milisegundos escrita por error, y esta página lo señala.
HS256 es HMAC con SHA-256. Un único secreto compartido firma y verifica, así que cualquier servicio que pueda comprobar un token también puede crear uno. RS256 es una firma RSA con SHA-256. El emisor firma con una clave privada y cualquiera verifica con la clave pública, que los proveedores suelen publicar como un conjunto JWK. HS256 conviene a un único sistema que emite y comprueba sus propios tokens; RS256, ES256 o EdDSA convienen a tokens que cruzan una frontera de confianza, como un proveedor de identidad y muchas API.
alg none marca un JWT no protegido: el segmento de firma está vacío, así que cualquiera puede escribir los claims que quiera. La especificación permite estos tokens, pero a un verificador que los acepte, o que deje que la propia cabecera del token decida qué algoritmo usar, se le puede colar un token falsificado. Configura tu biblioteca JWT con los algoritmos exactos que esperas y rechaza todo lo demás, incluido none.
Recalcúlala o compruébala sobre los dos primeros segmentos exactamente como aparecen en el token (la cabecera, un punto y luego la carga útil) usando la clave correcta. Para HS256 esa clave es el secreto compartido; para RS256, PS256, ES256 o EdDSA es la clave pública del emisor, que suele estar en el jwks_uri indicado en el documento /.well-known/openid-configuration del proveedor. Pega cualquiera de las dos en el verificador de arriba. Un verificador real comprueba además exp, nbf, iss y aud, porque una firma válida solo prueba quién creó el token, no que siga siendo aceptable.
Una cookie de sesión clásica contiene un ID aleatorio que el servidor busca en su propio almacén, así que cerrar sesión o revocar el acceso surte efecto de inmediato. Un JWT lleva consigo sus claims, así que cualquier servicio que tenga la clave puede comprobarlo sin hacer ninguna búsqueda, pero sigue siendo válido hasta exp incluso después de que el usuario cierre sesión, a menos que añadas una lista de bloqueo. Muchos sitios usan JWT de vida corta entre servicios y una sesión del lado del servidor para el navegador. Las dos opciones no son excluyentes: un JWT también puede guardarse en una cookie.
Un token JSON Web Encryption (RFC 7516) está cifrado en lugar de solo firmado. Su forma compacta tiene cinco segmentos: cabecera protegida, clave cifrada, vector de inicialización, texto cifrado y etiqueta de autenticación. Solo la cabecera es legible; los claims están dentro del texto cifrado y hace falta la clave privada o la clave compartida del destinatario para descifrarlos. Esta página reconoce un JWE, muestra su cabecera y dice claramente que los claims no se pueden leer sin la clave.
Explora una colección cada vez más amplia para cálculos, documentos, escritura y el trabajo diario.