Paste a JSON Web Token to read its header, its claims and when it expires. It is decoded in your browser and never sent to us.
| Claim | Meaning | Value |
|---|
A JSON Web Token (RFC 7519) is three pieces of text joined by dots. The first is a header naming the signing algorithm. The second is the payload: a set of claims about who the token is for and what it allows. The third is a signature over the first two.
The header and payload are encoded with base64url. They are not encrypted. Anyone who holds a token can read everything in it, exactly as this page does, with no key. That is the most common misunderstanding about JWTs and the reason personal data and secrets do not belong in one.
iss is who issued the token and aud is the service it
was issued for. A service must refuse a token whose audience is somebody else.
sub is the user or client it represents. exp is when
it stops being valid, nbf is when it starts and iat
is when it was issued. All three are seconds since 1970, which the decoder
turns into dates in UTC and in your local time.
When a login problem lands on your desk, these answer most of it: the token has expired, the audience is wrong, the scope or role you expected is missing, or the clock on a server is off.
It does not verify the signature. Verifying needs the shared secret or the
issuer's public key, and a secret should never be typed into a web page. So a
decoded token tells you what it says and not whether it is genuine. Your
application must verify every token with a maintained library, pin the
algorithms it accepts, and reject alg: none, as the JWT best
current practice document (RFC 8725) sets out. The decoder flags an unsigned
token and a token with no expiry when it sees one.
A token with five parts is an encrypted one (JWE). Its contents cannot be read without the key, and the decoder says so and stops.
The token is decoded by the script in this page and stays in your browser. The box has no form action and no field name, so nothing is submitted. Even so, treat a live access token like a password: it works for whoever holds it until it expires. Prefer a token from a test environment, and if a production token has been pasted into any site you do not control, revoke it.
Not normally. The header and payload are only base64url encoded, so anyone with the token can read them. The signature stops the contents being changed. It does not hide them. An encrypted token (JWE) has five parts where a signed one has three.
No. It shows what the token contains. Verifying needs the secret or the issuer's public key, and pasting a signing secret into a web page is a risk not worth taking. Verify in your application or with a local tool.
No. Decoding happens in your browser, and the page makes no request with the token. Still, use test tokens where you can, and revoke any production token you have shared more widely than intended.
Read the exp claim. It is a number of seconds since 1 January 1970 UTC. The decoder shows it as a date and tells you how long is left or how long ago it expired. A token with no exp claim does not expire by itself.
It means the token carries no signature at all. Anyone can write such a token with any claims they like. A service that accepts it can be logged into as anyone, so libraries should be configured to accept only the algorithms you actually use.