JWT Decoder

What the JWT Decoder Does

A JWT (JSON Web Token) is a short string that carries authentication and session information, and it is only a Base64URL-encoded JSON string — not encrypted, and not secret. This decoder splits any JWT into its header, payload and signature in your browser, without sending it anywhere, and reads the time claims for you: issued at (iat), not before (nbf) and expires at (exp), each shown in UTC and in your local time.

How to Use the JWT Decoder

• Paste your token into the JWT box, or click Load sample to try it with a ready-made token.

  

• The results appear as you type or paste; click Decode to run it again at any time.

  

• Read the three result panes — Decoded header (the signing algorithm and token type), Decoded payload (the claims) and Signature (shown as Base64URL text, not verified).

  

• Check the Time claims panel underneath: it converts iat, nbf and exp into readable dates and labels the token, for example “active (nbf passed)” or “expired”.

  

• Click Copy header or Copy payload to take the decoded JSON.

  

• Click Clear — the button under the box, or the Clear link above it — to reset and decode another token.

  

All the work is done in your browser in JavaScript. Decoding a token fires no network requests at all, so nothing is uploaded or stored.

What Is a JWT?

• A JWT has three parts — header, payload and signature — each Base64URL encoded and separated by dots.
• The header names the signing algorithm (for example HS256 or RS256) and the token type, which is normally JWT.
• The payload carries the actual data: a user ID, roles, an expiry time and any custom fields the application adds.
• The signature is a cryptographic value derived from the header and payload with a secret or private key, used to prove the token has not been altered.
• The header and payload are only encoded, not encrypted, which means anyone can read them — which is exactly what this tool does.
• JWTs are widely used in APIs, single sign-on and microservices, where the token itself carries everything the server needs to identify a request.

Decoding vs. Verifying — Know the Difference

Every JWT tool sits on one side of this line, and it is the limitation this decoder is explicit about:

• Decoding takes the Base64URL-encoded header and payload and turns them back into readable JSON. No key or secret is needed, because the data is encoded, not encrypted.
• Verifying recomputes the signature and compares it against the secret or public key of the trusted source that issued the token.
• This tool only decodes. It does not check the signature and cannot tell you whether a token is valid or has been modified — the page says so under the Signature box.
• Decoding alone is never enough to trust a token: one with a forged signature still decodes into perfectly normal-looking header and payload data.
• Applications that consume JWTs should always verify the signature with the right library for their language and algorithm, and never assume a token is genuine just because it decoded cleanly.

Common Payload Claims

A payload mixes standard registered claims with custom fields — knowing the standard ones makes any decoded token far easier to read:

• iss (issuer) — who issued the token
• sub (subject) — who the token is about, usually a user ID
• aud (audience) — who the token is intended for
• exp (expiration time) — when the token stops being valid, as a Unix timestamp
• nbf (not before) — the earliest time the token becomes valid
• iat (issued at) — when the token was created
• jti (JWT ID) — a unique identifier for this particular token
• Beyond these registered claims, applications commonly add custom fields such as name, role, email or permissions.

The decoder converts exp, nbf and iat for you in its Time claims panel, so you never have to work out a Unix timestamp by hand.

When You’d Use a JWT Decoder

• Working out why an API call was rejected, by reading the claims in the token that was sent.
• Checking a token’s exp claim after a session ended sooner than expected.
• Seeing what a login or SSO flow actually puts into the tokens it issues.
• Confirming during development that a JWT carries the claims you expect, before wiring up server-side logic.
• Learning how a JWT is put together by decoding a real one and reading its header, payload and signature.
• Reading a token pasted into a bug report, log or support ticket without writing a decoding script.

Worked Example

Encoded JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE3MzU2ODk2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoded header:

{ "alg": "HS256", "typ": "JWT" }

Decoded payload:

{ "sub": "1234567890", "name": "Jane Doe", "iat": 1516239022, "exp": 1735689600 }

Time claims:

Issued at (iat): 2018-01-18T01:30:22.000Z — Expires at (exp): 2025-01-01T00:00:00.000Z — Status: expired

This is the token behind the Load sample button, so you can click it and follow along. Notice that it starts with eyJ — the Base64URL encoding of {“, the opening of a JSON object whose first key is a string, which is why almost every JWT begins the same way.

Do’s and Don’ts

Do

• Decode JWTs while debugging or developing to see what a token actually contains.
• Verify the signature server-side before trusting or acting on any claim in a token.
• Check exp and iat when you are troubleshooting unexpected session expiries — the Time claims panel does the conversion for you.
• Treat any JWT you paste into a tool, this one included, as a live credential.

Don’t

• Don’t treat a clean decode as proof that a token is genuine — decoding does not validate the signature.
• Don’t paste production JWTs carrying sensitive claims into third-party tools you have not checked.
• Don’t confuse Base64URL encoding with encryption: the payload is readable by anyone, with no key at all.
• Don’t let client-side or manual decoding stand in for proper server-side signature verification in your application.

Common Mistakes

• Treating decoding as proof of authenticity. A tampered or completely fabricated JWT still decodes into readable JSON. Signature verification is the only way to detect forgery.
• Assuming the payload is private. It is only encoded, not encrypted, so anyone who intercepts the token can read every claim in it.
• Ignoring token expiry while debugging. An exp that has already passed explains a large share of “why is my token being rejected” problems — and the decoder labels that token expired.
• Skipping server-side verification altogether, relying on the decoded claims and never comparing the signature against the key from the authentication flow.

Good to Know

• JWTs are URL-safe by design: Base64URL uses – and _ in place of + and /, so a token can travel in a URL or a header without extra escaping.
• The eyJ prefix on the header (and usually the payload) is the quick visual cue that you are looking at Base64URL-encoded JSON.
• exp, nbf and iat are Unix timestamps — seconds since 1 January 1970 — and are not readable dates until they are converted. This decoder shows both UTC and your local time.
• JWTs are defined by RFC 7519, and the registered claim names (iss, sub, aud, exp and so on) mean the same thing across different systems.
• A JWT’s signature depends on the algorithm named in its header (alg): HS256 uses a shared secret, while RS256 and ES256 use a public/private key pair.
• If the tool answers “A JWT must have three parts separated by dots”, a segment or a dot is missing; “Decoded segment is not valid UTF-8” means what you pasted is not a JWT at all.

FAQ