Ir al contenido
DevTools / Decodificador JWT

Decodificador JWT

A JSON Web Token is three Base64URL segments joined by dots, and half the difficulty of debugging one is simply seeing what is inside it. This decoder splits a token into its header, payload and signature, explains every registered claim, renders expiry and not-before times as a human countdown, and can verify the signature against an HMAC secret or an RSA public key so you know whether a rejection came from the token itself or from the key your service is using.

Se ejecuta por completo en tu navegador: no se sube nada.

Cómo funciona

A JWT has the form header.payload.signature, where the first two segments are Base64URL-encoded JSON. The header declares the signing algorithm in alg and the key identifier in kid; the payload carries the claims, which are just JSON key-value pairs. The signature is computed over the literal string header.payload — the exact bytes, including the encoding — using the algorithm named in the header and a key known to the issuer. Decoding the first two segments requires no key at all, which is a common source of confusion: Base64URL is an encoding, not a protection.

Registered claims have fixed meanings. iss identifies the issuer, aud the intended audience, sub the subject, exp the expiry as a Unix timestamp, nbf the moment the token becomes valid, iat when it was issued, and jti a unique identifier used for revocation lists. Validation is not merely a matter of decoding: a service must check that the signature verifies, that the current time is between nbf and exp, that iss matches its own identity, and that aud includes it. A token that decodes cleanly and has not expired can still be rejected for any of the other reasons.

The algorithms split into two families. HS256, HS384 and HS512 are HMAC: the same secret key signs and verifies, which is fine when a single backend owns both ends but means every party that can verify can also forge. RS256 and ES256 are asymmetric: the issuer signs with a private key and services verify with the public key, so a compromised verifier cannot mint tokens. The none algorithm means no signature at all, and the classic JWT vulnerability is a library that reads alg from the token header and accepts none, or accepts HS256 while the server verifies with what is actually an RSA public key.

Signature verification matters because a decoded payload proves nothing on its own. Anyone can craft a token with an admin role and a future expiry; only the signature binds those claims to the issuer. This tool recomputes the signature locally — HMAC through the Web Crypto API for HS*, and RSA-PSS or RSASSA-PKCS1-v1_5 for RS* — and reports a byte-exact comparison, so an invalid-signature error in production can be traced to a wrong secret, a wrong algorithm or a truncated token rather than guessed at.

Casos de uso habituales

  • Inspect the claims in a token copied from an Authorization header to find out which tenant or role it carries.
  • Work out whether an expired-token error is genuine by reading the exp timestamp as a date.
  • Verify a webhook signature with a shared secret to confirm your HMAC code is correct.
  • Check that an identity provider is actually sending the audience your API expects.
  • Trace a 401 by comparing the alg and kid in the token against the keys your service has configured.
  • Confirm that a token contains no sensitive personal data before logging it.

Última actualización: 2026-10-14 — el cuerpo del artículo se muestra en inglés; la interfaz está traducida.

Preguntas frecuentes

Is it safe to paste a production JWT here?

Decoding happens entirely in your browser, so the token is never transmitted — you can confirm this by watching the network panel. Treat the token itself as a credential regardless: a valid JWT is a bearer token, meaning anyone holding it can act as its subject until it expires. Prefer a token from a staging environment, and if you must use a production one, revoke or let it expire afterwards rather than leaving it in a chat log or browser history.

My token decodes fine but the API returns 401. Why?

Decoding and validating are different operations. The three usual causes are an expired exp, an audience or issuer mismatch, and a signature that does not verify against the key the service is using. Check exp and nbf first because they are visible without a key, then compare the alg and kid in the header against the service configuration. A clock skew of more than a minute or two between the issuer and the verifier will also reject a token that looks perfectly valid.

Why is the payload readable if the token is signed?

Because a signature proves origin and integrity, not confidentiality. The payload is Base64URL-encoded, which is a reversible encoding anyone can undo — signing does not encrypt. A JWT is a statement the issuer signs, like a passport; it is not a sealed envelope. Never place secrets, personal data or anything you would not put in a URL into a JWT payload, and use encrypted tokens (JWE) if the claims genuinely need to be confidential.

Should I accept the none algorithm?

No, and your library should not either. Accepting alg: none means accepting unsigned tokens, which lets anyone forge any identity. The related attack is algorithm confusion: an attacker changes alg from RS256 to HS256 and signs with the public key, which the server then uses as an HMAC secret. The defence in both cases is to pin the expected algorithm in your verification configuration and never read it from the token header.

Herramientas relacionadas