Free JWT Decoder
Paste a token to read its header and claims, see when it expires, and catch unsigned tokens before you trust them.
What is a JWT Decoder?
A JWT decoder reads a JSON Web Token, the dot-separated string many APIs use for logins and access. It splits the token into its header, payload and signature, decodes the first two from Base64url, and shows the claims inside as readable JSON.
This tool follows RFC 7519 for JWTs and RFC 7515 for their compact form. It shows the exp, nbf and iat claims as dates and says whether each is in the past, and it warns when a token uses alg none. It reads the signature but doesn’t verify it, because verification needs the issuer’s secret or public key.
Key Features
Claims You Can Read at a Glance
Header and payload are shown as formatted JSON, or compact JSON when you want to paste them elsewhere. Custom claims appear exactly as the issuer wrote them.
Expiry Explained in Plain Dates
exp, nbf and iat are converted from Unix seconds to UTC dates, each marked as past or future. You see at once whether a token is expired or not yet valid.
Unsigned Tokens Flagged
A token with alg none or an empty signature gets a warning, because anyone can forge one. Accepting these is a well-known authentication bug.
Pastes Straight From a Header
A Bearer prefix copied from an Authorization header is ignored, and surrounding spaces are trimmed. Paste what you have; no editing needed.
Tokens Stay on Your Machine
Decoding happens in your browser, so a live session token is never sent to a server or logged. That matters, because a valid JWT is as good as a password.
Perfect for everyone
- Backend developers debugging authentication
- Frontend developers checking login state
- QA engineers testing session expiry
- Security reviewers auditing token contents
How to Use the JWT Decoder
Paste a token and read what it contains.
Copy the Token
Take the token from an Authorization header, a cookie, local storage or a login response. A Bearer prefix is fine to include, since it is removed before decoding.
Paste It Into the Token Field
The header, payload, times and signature appear straight away. Choose Pretty for indented JSON or Compact for one line you can paste into a ticket.
Check the Times and Warnings
Read the Times block to see whether exp has passed or nbf is still ahead, in UTC. A warning at the top means the token is unsigned and must never be trusted.
Copy the Claims You Need
Copy the payload into your bug report or test, or download it as a text file. Keep the original token out of tickets and chats, since it may still grant access.
JWT Claims and Header Fields
RFC 7519 registers seven claim names, and RFC 7515 defines the header fields. These are the ones you will see in almost every token.
iss: Issuer
Names who created the token, usually the identity provider’s URL. An API should reject tokens from any issuer it doesn’t expect.
“Which claim says who issued the token?”
sub: Subject
Identifies the user or client the token is about, often a stable user ID. It must be unique within the issuer.
“Which claim holds the user ID?”
aud: Audience
Lists the services the token is meant for, as one string or an array. A token issued for one API should be refused by another.
“Can aud be an array?”
exp: Expiration Time
A NumericDate, in seconds since 1970, after which the token must be rejected. Short-lived access tokens often expire within an hour.
“Is exp in seconds or milliseconds?”
nbf: Not Before
The token must not be accepted before this time. Issuers set it to delay activation or to allow for clock skew.
“What happens before nbf?”
iat: Issued At
When the token was created, also in seconds. Comparing iat with exp shows how long the token was meant to live.
“What does iat record?”
jti: JWT ID
A unique ID for this token, used to detect replays or to revoke a single token from a deny list.
“Which claim helps block replays?”
alg: Signing Algorithm
A header field naming how the token is signed, such as HS256, RS256 or ES256 from RFC 7518. none means no signature at all.
“What does alg: none mean?”
kid: Key ID
Tells the verifier which key from the issuer’s key set signed the token. It is how key rotation works without breaking old tokens.
“Which header field picks the signing key?”
typ: Media Type
Usually JWT, or a more specific value like at+jwt for OAuth access tokens under RFC 9068. It helps a service avoid confusing one token type with another.
“What typ do OAuth access tokens use?”
Tokens Decoded by This Tool
Each row is a token pasted into this tool and the exact payload it returned in Compact view, or the error it showed. Several are the published examples from the JWT specification.
“eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c”
“eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk”
“eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.”
“Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c”
“eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwibmJmIjoxNzkzNDgzMjAwLCJleHAiOjE3OTQwODgwMDB9.sig”
“eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0”
“eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4R0NNIn0..2iqKx9HfqROVYpNE.d8T8mUJs7sQ.Rr-NGM_RJRKUbtM9t1C3mA”
“eyJhbGciOiJIUzI1NiJ9.bm90IGpzb24.abc”
“eyJhbGciOiJIUzI1NiJ9.WzEsMiwzXQ.abc”
“eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyLTQyIn0!.abc”
Supported JWT Specifications
JWTs sit on a family of RFCs, and this tool reads the parts that matter for inspecting a token.
RFC 7519, JSON Web Token
Defines the token itself, the registered claims and the NumericDate format. Every claim in the Field Reference comes from this RFC.
RFC 7515, JWS Compact Serialisation
Defines the three-part, dot-separated form decoded here. The JSON serialisation of JWS, used by a few systems, isn’t read.
RFC 7516, JSON Web Encryption
Encrypted tokens have five segments and are recognised, but not decrypted. Only the holder of the recipient’s key can read their payload.
RFC 7518, Signing Algorithms
Names the alg values you will meet, such as HS256, RS256, ES256 and none. The algorithm is displayed exactly as the header states it.
RFC 8725, JWT Best Practices
The current security guidance warns about alg none and algorithm confusion. That is why unsigned tokens are flagged here instead of quietly decoded.
RFC 9068, OAuth Access Tokens
Profiles JWT access tokens with typ at+jwt and required claims such as aud and client_id. Those tokens decode like any other JWT.
RFC 7517, JSON Web Keys
Issuers publish their public keys as a JWK Set, and the kid header points into it. Verifying a token means fetching that set, which this tool deliberately doesn’t do.
OpenID Connect ID Tokens
Sign-in providers return an ID token, a JWT that must carry iss, sub, aud, exp and iat, plus a nonce when one was sent. Decode it here to see which profile claims a provider includes.
What the Error Lines Mean
Each failed decode points to one cause, and most have a quick fix.
Wrong Number of Segments
A signed JWT has exactly two dots. Two segments usually means the signature was cut off when copying, and four or more means extra text came along.
Encrypted JWE Detected
Five segments mean the payload is encrypted with the recipient’s key. You can still read its header, but not its claims, without that key.
Segment Isn’t Valid Base64url
A space, line break or stray character got into the token, often from a chat app or email. Copy it again directly from the source.
Payload Isn’t JSON
The middle segment decoded to text that isn’t JSON, so this is probably an opaque token from an OAuth server. Use the provider’s introspection endpoint to read it.
Payload Isn’t an Object
JWT claims must be a JSON object, so an array or a bare string can’t be a valid token. Check the code that created it.
Empty Header or Payload
Two dots side by side, as in a..b, leave a segment empty. Only the signature may be empty, and only in an unsigned token.
Read the Header When All Else Fails
If a token from an unknown system won’t decode, paste only its first segment into a Base64url decoder. The header’s alg and typ usually reveal what kind of token it is.
Header Isn’t JSON
If the first segment doesn’t decode to JSON, the string isn’t a JWT at all. It may be a random session ID or an opaque token that only its issuer can read.
When Developers Decode JWTs
Most JWT debugging starts with reading what the token actually says.
Debugging a 401 Response
Decode the token your app sent and check exp, aud and iss against what the API expects. Most unexplained 401s come down to one of those three.
Checking Roles and Scopes
Confirm that a token carries the role, scope or permission claim your feature checks. Missing claims usually trace back to the identity provider’s configuration.
Testing Session Expiry
Read exp and iat to see how long tokens live, then test what happens when they lapse. The Times block shows the exact expiry in UTC.
Reviewing a Third-Party Login
Decode an ID token from Google, Microsoft or Auth0 to see which profile claims it includes before wiring up sign-in.
Auditing for Unsafe Tokens
Paste tokens from a staging system to catch alg none or long-lived tokens before they reach production. RFC 8725 lists both as common mistakes.
Writing a Bug Report
Copy the decoded payload, not the raw token, into a ticket. Teammates see the claims without being handed a token that may still work.
Learning How Tokens Work
Decode the RFC 7519 example and compare its claims with the spec. Seeing exp turn into a date makes NumericDate obvious.