JWT Decoder — Inspect Token Payload, Nothing Leaves Your Browser
Decode any JWT's header and payload instantly to inspect claims, timestamps, and metadata. Your token never leaves your browser — critical since JWTs are credentials. No server, no account, no logs.
How to use this tool
- Paste a JWT token into the input field.
- The header and payload are decoded and displayed instantly.
- Inspect claims, expiry timestamps, and issuer information.
About JWT Decoder
A JSON Web Token (JWT) is a compact, URL-safe way to carry claims between two parties. It has three parts separated by dots: header.payload.signature. The header and payload are JSON objects that have been Base64URL-encoded, and the signature is computed over the first two parts using the algorithm named in the header. Because the first two segments are merely encoded — not encrypted — anyone holding the token can read everything inside it. This decoder splits the token, decodes the header and payload, and shows you the JSON so you can inspect exactly what a service is asserting about a session.
Base64URL is a variant of Base64 that swaps the + and / characters for - and _ and drops the trailing = padding, so the result is safe to place in URLs and HTTP headers. The header typically contains alg (the signing algorithm, such as HS256 or RS256) and typ. The payload contains claims: registered ones like iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), and iat (issued at), plus any custom claims an application adds. The time-based claims are Unix timestamps in seconds; this tool renders them in human-readable UTC so you can immediately see whether a token has expired.
Critically, this tool does not and cannot verify the signature. Verification requires the secret key (for HMAC algorithms like HS256) or the issuer's public key (for asymmetric ones like RS256 or ES256), and it is the only thing that proves a token is authentic and untampered. A decoder shows you the claims; it does not tell you whether to trust them. Signature verification belongs on the server that consumes the token, never in a throwaway client tool, because that is where the key lives.
This matters for where you decode. A JWT is a bearer credential: whoever holds a valid, unexpired token can act as that user until it expires. Pasting a live production token into a typical online decoder sends that credential to someone else's server, where it can be logged. Here, decoding runs entirely in your browser via the native atob function, so the token never leaves your device — which is the only safe way to inspect a real token. Use it to debug why an auth flow rejects a request, to read which scopes a token grants, or to confirm an expiry, but rotate any token you ever suspect was exposed.
Frequently Asked Questions
- Does this tool verify the token's signature?
- No. It decodes only the header and payload so you can read the claims. Verifying the signature requires the signing secret or the issuer's public key and proves the token is authentic and unmodified. That check must happen on the server that consumes the token, never in a client-side decoder, because the key must stay private.
- Is my token sent anywhere?
- No. The token is split and Base64URL-decoded entirely in your browser. It never touches a server. This is important because a JWT is a bearer credential — anyone who captures a valid one can impersonate the user until it expires, so pasting a live token into a server-side online decoder is a real risk.
- What do iat, exp, and nbf mean?
- They are time-based claims expressed as Unix timestamps in seconds. iat is when the token was issued, exp is when it expires, and nbf (not before) is the earliest time the token is valid. This tool converts them to readable UTC so you can see at a glance whether a token is currently within its valid window.
- Why is my token shown as invalid?
- A JWT must be exactly three Base64URL-encoded segments separated by two dots: header.payload.signature. If you have the wrong number of dots, or the header or payload is not valid Base64URL-encoded JSON, decoding fails. A common mistake is copying only part of the token or including surrounding quotes or whitespace.
- Can I read a token even if it is expired?
- Yes. Decoding does not check validity; it just reads the claims. So an expired, revoked, or otherwise rejected token still decodes fine, and the human-readable exp timestamp is often exactly what you need to confirm that expiry is the reason a request was refused.
- What is the difference between a JWT and an encrypted token?
- A standard signed JWT (a JWS) is encoded, not encrypted — its contents are fully readable by anyone. If a payload must be confidential, the JWE variant encrypts it, and a plain decoder cannot read those contents without the decryption key. Never put secrets you would not want a user to see inside an ordinary signed JWT.
- Does the alg header value tell me whether the token is secure?
- It tells you which algorithm was used to sign it, such as HS256 (HMAC) or RS256 (RSA). It does not prove the signature is valid. Be aware that the 'none' algorithm means the token is unsigned; a correctly built server must reject 'none' rather than treat such a token as trusted.
Embed this tool on your site
Free. One line of HTML — the tool runs in your visitor's browser, no data sent to anyone.
<iframe src="https://brevio.pro/embed/jwt-decoder" width="100%" height="600" loading="lazy" style="border:1px solid #e5e5e5;border-radius:8px" title="JWT Decoder — brevio"></iframe> <p style="font:12px/1.4 sans-serif"><a href="https://brevio.pro/tools/jwt-decoder">JWT Decoder</a> by <a href="https://brevio.pro">brevio</a></p>