Fast, practical, browser-based developer tools
Decode JWT header and payload instantly in your browser. Inspect claims such as
exp, iat, sub, aud, and other token fields
for development, debugging, and authentication workflows. This tool decodes token contents only
and does not verify signatures.
JWT tokens are commonly used in authentication and authorization systems. During development, debugging, and integration testing, it is often useful to inspect the token header and payload to see which claims are present and whether the token structure looks correct. This tool helps you decode those parts quickly without sending the token to a backend as part of the normal tool flow.
This page only decodes the token contents. It does not verify the JWT signature, validate the token against a secret or public key, or confirm that the token is trusted.
Decoding a token helps you inspect its contents, but it does not prove authenticity. Always perform signature verification in your application or backend security workflow.
Paste a JWT token into the input area and click Decode JWT. The tool will split the token into its three segments, decode the header and payload from Base64URL, and show them as formatted JSON when possible.
JWT tokens usually contain three sections separated by dots:
header.payload.signature
This tool decodes the first two parts into readable JSON and shows the third part as the signature segment for reference.
A JWT has three dot-separated parts: header.payload.signature. The header and
payload are nothing more than Base64url-encoded JSON — not encrypted, not
signed data, just reversible encoding. Decoding a JWT means Base64url-decoding those parts,
which is exactly what this tool does. It reads the token; it does not trust it.
The consequence people miss: anyone holding the token can read every claim inside it. The signature stops a token from being modified undetected; it does nothing to hide the contents. So never put anything sensitive — passwords, API keys, personal data you would not log — in a JWT payload. If you can paste it here and read it, so can anyone who intercepts it.
Verifying a JWT is a separate, server-side step that needs the signing key, and it has two
halves. First, the signature: recompute it over
header.payload with the expected key and confirm it matches, which proves the
token was issued by someone holding the key and has not been altered. Second, the
claims:
exp — reject if the expiry time has passed.nbf — reject if the "not before" time has not yet arrived.iss — confirm the issuer is who you expect.aud — confirm the token was intended for your service, not another.A valid signature on a token issued for a different audience, or one that expired yesterday, must still be rejected. Checking the signature alone is not enough.
Two classic JWT vulnerabilities both come from letting the token's own header
choose how it is verified. In the alg:none attack, an attacker sets
the header algorithm to none and strips the signature; a naive verifier that
honours the header accepts the unsigned token as valid.
The algorithm-confusion attack is subtler. RS256 is asymmetric: the server
signs with a private key and verifies with a public one that is not secret. If the attacker
changes the header to HS256 and signs the token using the server's
public key as an HMAC secret, a verifier that reads the algorithm from the token
will HMAC-verify with that same public key — and it matches. The public key was never meant
to be a secret, so the forgery succeeds. The fix for both is the same:
pin the expected algorithm server-side and never let the token dictate it.
No. Decoding is just Base64url-decoding the header and payload — it never checks the signature. A decoded token could be expired, forged, or issued for a different service. Verification requires the signing key and happens on your server.
Yes. The payload is only Base64url-encoded, not encrypted, so anyone holding the token can read every claim. Never store secrets or sensitive personal data in a JWT payload; the signature protects integrity, not confidentiality.
The header (algorithm and type), the payload (the claims), and the signature. The first
two are Base64url-encoded JSON; the signature is computed over
header.payload and is the only part that requires a key to produce or check.
The claims: exp (not expired), nbf (already valid),
iss (expected issuer), and aud (intended for your service). A
perfectly signed token that expired or was meant for another audience must still be
rejected.
Both abuse a verifier that trusts the token's alg header. alg:none
strips the signature entirely; the confusion attack re-signs an RS256 token as HS256 using
the public RSA key as the HMAC secret. Pin the expected algorithm on the server so the
token cannot choose its own verification method.
You largely cannot — that is the trade-off of stateless tokens. A signed JWT stays valid
until exp. Practical answers are short expiry times paired with refresh
tokens, or a server-side denylist of revoked token IDs, which reintroduces state but lets
you cut off a compromised token immediately.