Decode JWT header and payload, inspect claims and expiration — without the token leaving your browser.
A JSON Web Token (JWT, RFC 7519) is three Base64URL-encoded segments separated by dots: a header that names the signing algorithm, a payload carrying the claims — who issued the token, for whom, and until when it is valid — and a signature. JWTs are the standard bearer credential of OAuth 2.0 and OpenID Connect, which is why debugging a login flow or an API integration so often starts with the question: what is actually inside this token?
This decoder splits the token on the dots, restores the Base64URL padding, decodes each segment as UTF-8 and pretty-prints the JSON. It highlights the registered claims — iss (issuer), sub (subject), aud (audience), iat (issued at), nbf (not before) and exp (expiration) — converting the numeric timestamps, which count seconds since the Unix epoch, into readable UTC dates. The expiration is also compared against your clock, so the status tells you at a glance whether the token is still valid and for how long, or how long ago it expired. Malformed input produces a clear, friendly error instead of a cryptic exception.
One thing must be said as loudly as possible: decoding a JWT is not validating it. The header and payload are merely Base64URL-encoded — anyone can read them and anyone can forge them. Only the signature, checked against the issuer's secret or public key, proves a token is authentic, and this tool deliberately does not do that: signature verification belongs on your server, with a proper JWT library. For the same reason, never put passwords or other secrets in a JWT payload — encoded is not encrypted. The token you paste here is decoded entirely in your browser and never transmitted, but treat production tokens as the credentials they are.
No — it only decodes the header and payload, and it says so on every result. A decoded token proves nothing about authenticity: verify the signature on your server with the issuer's key and a proper JWT library before trusting any claim.
No. In a standard signed JWT (JWS) the header and payload are only Base64URL-encoded, readable by anyone who holds the token. Encrypted JWTs (JWE) exist but are rare; never store secrets in a normal JWT payload.
They are timestamps in seconds since the Unix epoch: iat is when the token was issued, nbf is the moment before which it must be rejected, and exp is when it expires. This tool converts all three to readable UTC dates and computes the expiration status for you.
The most common causes are pasting something that is not a compact JWT (it must have exactly three dot-separated parts), a token truncated by a copy-paste, or extra characters around it. The "Bearer " prefix is handled automatically; anything else around the token is not.
No. Decoding happens 100% locally in JavaScript — the token is never transmitted, logged or stored. Even so, a production JWT is a live credential: avoid sharing screenshots of it and revoke tokens you suspect were exposed.
Vai.la turns any URL into a short link with click statistics, QR Code and your own biolink.
Vai.la is not responsible for how the tools are used or for decisions made based on their results.