About this tool
A JWT decoder is a utility that splits a JSON Web Token into its three dot-separated parts and reverses the Base64url encoding so you can read the header and payload as plain JSON. It is the fastest way to inspect what an authentication token actually claims without writing any code.
JSON Web Tokens were standardised in RFC 7519 (2015) and are now the default bearer-token format for OAuth 2.0, OpenID Connect, and most stateless API authentication. Because the header and payload are merely encoded rather than encrypted, a decoder needs no key to reveal them. Developers reach for one constantly while debugging logins, checking why a token was rejected, confirming which scopes or roles a token grants, or reading the expiry during an incident.
How it works
A JWS-format JWT is three Base64url strings joined by dots. The decoder splits on the dots, undoes the URL-safe character swaps, re-adds padding, and decodes each segment back to text. The first two segments are JSON; the third is the raw signature. No key, network call, or library is needed for this step, which is exactly why the header and payload should never be treated as secret.
token = base64url(header) "." base64url(payload) "." base64url(signature)
decode(segment):
s = segment.replace("-", "+").replace("_", "/")
while length(s) mod 4 != 0: s = s + "=" // restore padding
return atob(s) // Base64 to bytes
- header = JSON naming the signing algorithm (alg) and token type (typ), for example {"alg":"HS256","typ":"JWT"}.
- payload = JSON of claims: subject (sub), issued-at (iat), expiry (exp), plus any custom fields.
- signature = a keyed hash over header and payload; it cannot be reversed to text and is not decoded.
- exp / iat / nbf = Unix timestamps in seconds; the decoder multiplies by 1000 to get a JavaScript date.
Worked example
Take the sample token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE5OTk5OTk5OTl9... and decode it by hand:
- Split on dots: three parts, so the structure is valid.
- Decode part 1:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9becomes {"alg":"HS256","typ":"JWT"}. - Decode part 2: the payload becomes {"sub":"1234567890","iat":1700000000,"exp":1999999999}.
- Read iat: 1700000000 seconds is 14 Nov 2023, the moment the token was issued.
- Check exp: 1999999999 seconds is 18 May 2033, which is in the future, so the token is still valid.
Common JWT algorithms and claims
The header alg value tells your server which key and method to use for verification. The payload mixes registered claims (reserved names from RFC 7519) with whatever custom data the issuer adds.
| Field | Type | Meaning |
|---|---|---|
| HS256 | alg | HMAC + SHA-256, one shared secret signs and verifies |
| RS256 | alg | RSA + SHA-256, private key signs, public key verifies |
| ES256 | alg | ECDSA + SHA-256, smaller keys, common in mobile and IoT |
| none | alg | Unsigned, must be rejected by servers (a classic exploit) |
| iss / aud | claim | Issuer and intended audience of the token |
| exp / nbf / iat | claim | Expiry, not-before, and issued-at Unix timestamps |
Common pitfalls
- Trusting the payload without verifying the signature. Anyone can forge claims and re-encode them. Your server must verify the signature before acting on any claim.
- Accepting alg: none. A token claiming "none" has no signature; libraries that honour it let attackers mint any identity. Pin the expected algorithm server-side.
- Putting secrets in the payload. Base64url is reversible, so passwords or card numbers in a JWT are effectively public. Use JWE if the contents must stay private.
- Confusing seconds with milliseconds. JWT timestamps are seconds; JavaScript dates are milliseconds. Forgetting the x1000 makes 2033 look like 1970.
- Ignoring clock skew. A token can look expired only because two servers disagree on the time. Allow a small leeway (30 to 60 seconds) when checking exp and nbf.
- Long expiry with no revocation. A stateless JWT stays valid until exp even if the user logs out. Keep lifetimes short and pair with refresh tokens or a denylist for sensitive actions.
Related tools
Frequently asked questions
Is it safe to paste a JWT into this decoder?
Yes. The decoder runs entirely in your browser using the built-in atob function. The token is never sent to 3Tej or any server, nothing is logged, and the value disappears when you close the tab. That said, never paste a live production token into any online tool you do not trust, because a JWT often grants full account access until it expires.
Why is Base64url different from regular Base64?
JWTs use Base64url, a URL-safe variant defined in RFC 4648. It replaces the plus sign with a hyphen and the forward slash with an underscore, and it drops the trailing equals-sign padding. This lets a token sit inside a URL or HTTP header without being re-encoded. The decoder reverses those substitutions and re-adds padding before decoding.
Can this tool verify the JWT signature?
No. The header and payload are only Base64url-encoded, so anyone can read them, but the signature is a cryptographic hash that requires the secret key (for HS256) or the public key (for RS256 and ES256) to verify. Decoding proves what a token claims; only signature verification on your server proves the token is authentic and untampered.
What do the iat, exp, and nbf claims mean?
They are registered claims defined in RFC 7519, all expressed as Unix timestamps in seconds. iat is issued-at (when the token was created), exp is the expiry time after which the token must be rejected, and nbf is not-before (the token is invalid until this time). The decoder converts exp to your local time and flags the token as expired if exp is in the past.
Is a JWT encrypted or just encoded?
A standard signed JWT (JWS) is encoded, not encrypted. The payload is readable by anyone who has the token, so you must never put passwords, card numbers, or other secrets in it. If you need the contents hidden, use JWE (JSON Web Encryption), which wraps the payload in a real cipher rather than reversible Base64url.