JWT Decoder
Decode JSON Web Tokens and inspect their claims — entirely in your browser. Your token never leaves the page.
- Runs in your browser
- No upload, no tracking
- Free forever
How it works
A JWT decoder reads the three dot-separated parts of a JSON Web Token — the header, the payload and the signature — and renders the base64url-encoded header and claims as readable JSON. Decoding is not the same as verifying: the contents are encoded, not encrypted, so anyone can read them, which is why this tool inspects but does not check the signature. It runs entirely client-side, so your token never leaves the page. It is built by JusDB, a managed database operations team, for the auth and session debugging that surrounds every application.
- 1
Paste a token
Drop a JWT into the input box, or click Load sample to try one. Use Reset to clear the token and results.
- 2
Decode it
Click Decode token to split the token and render its header and payload claims as labelled rows.
- 3
Inspect claims and expiry
Standard claims (iss, sub, aud, exp, iat, nbf, jti) are annotated, timestamps are shown as ISO dates and relative time, and a status badge flags Valid, Expired or Not Yet Valid.
- 4
Copy what you need
Copy the header or payload JSON with one click. The raw signature is shown but explicitly marked as not verified.
Frequently asked questions
- Is it safe to decode my JWT here?
- Yes. The decoder runs entirely in your browser using JavaScript. Your token is never sent to JusDB or any server. This tool decodes the header and payload only — it does not verify the signature.
- What is the difference between decoding and verifying a JWT?
- Decoding reads the header and payload from the token, which are base64url-encoded (not encrypted). Verifying checks the signature against a secret or public key to confirm the token was issued by a trusted source. This tool decodes only.
- What does "token expired" mean?
- JWTs contain an exp claim (expiration time) as a Unix timestamp. If the current time is past that timestamp, the token is expired and should not be accepted.
- What are standard JWT claims?
- Standard claims include iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at) and jti (JWT ID). The tool labels these automatically.
- Does it convert timestamps to readable dates?
- Yes. Numeric claims that look like Unix timestamps (such as exp, iat and nbf) are shown alongside their ISO date and a human-readable relative time, so you can tell at a glance when a token was issued or expires.
- What does the token status badge mean?
- It reads the exp and nbf claims and shows Valid, Expired, Not Yet Valid, or No Expiry. This is based purely on the timestamps in the payload — it does not verify the signature.
Understanding JWTs: structure, claims and the limits of decoding
A JSON Web Token is three Base64URL strings joined by dots: header.payload.signature. Base64URL is a URL-safe variant of Base64 (no +, / or trailing =), which is why a JWT travels cleanly inside an Authorization header or a query string. The header describes how the token was signed, the payload carries the claims, and the signature binds the two together. Crucially, all of this is encoded, not encrypted — the decoder above simply reverses the encoding so you can read what is already public.
What the registered claims actually mean
The JWT spec reserves a small set of claim names, each three letters to keep tokens compact. iss (issuer) names who minted the token; sub (subject) is the principal it describes, usually a user ID; aud (audience) is the service the token is intended for, and a resource server should reject tokens whose audience is not itself.
The time claims are Unix seconds: exp (expiry) and nbf (not before) bound the validity window, iat (issued at) records when it was created, and jti (JWT ID) gives a unique identifier you can track to support one-time use or revocation lists.
Decoding is not verifying
Reading a payload tells you what a token claims; it tells you nothing about whether those claims are trustworthy. Verification is a separate, server-side step: you recompute the signature over the header and payload using the signing key, and accept the token only if it matches and the time claims are current. A client that trusts an unverified payload is trivially spoofable — anyone can hand-craft a JSON object and Base64URL-encode it.
For symmetric algorithms such as HS256 you verify with the same shared secret used to sign. For asymmetric algorithms such as RS256 or ES256 you verify with the issuer's public key, so the secret never has to leave the issuer. Need a token to test that flow? Mint one with the JWT generator.
Algorithm pitfalls to watch for
The header's alg field is itself an attack surface. Older libraries honoured "alg": "none", letting an attacker strip the signature and walk straight in; never accept unsigned tokens. The related algorithm-confusion attack abuses libraries that pick the verification method from the token: an attacker switches an RS256 token to HS256 and signs it with the public RSA key — which is, after all, public — as if it were an HMAC secret. The defence is to pin the expected algorithm in your verifier rather than trusting whatever the header announces.
Treat tokens as credentials. Because the payload is only encoded, never place secrets, passwords or sensitive PII inside it — assume anyone holding the token can read every claim. And avoid pasting production tokens into random online decoders, since many post them to a server. This decoder runs entirely client-side: your token is parsed in the browser and never leaves the page. If you only need to peek at the raw segments, the Base64 encoder & decoder will reveal the same bytes.