JWT Decoder
Paste a JSON Web Token and instantly read its header and payload as formatted JSON, with the expiry and issued-at timestamps turned into readable dates. The token is decoded entirely in your browser — nothing is uploaded, so it is safe to inspect a live token.
What is the JWT Decoder?
The JWT decoder is a free online tool that takes a JSON Web Token and splits it back into the pieces it was built from, so you can actually read what is inside. A JWT looks like one long, opaque string, but it is really three Base64URL-encoded parts joined by dots. This tool decodes the header and payload into clean, formatted JSON and translates the time-based claims into dates a person can read, which is exactly what you need when you are debugging why a login worked, failed, or expired.
How to use it
- Copy a token from your network tab, your auth provider's dashboard, or a curl response and paste it into the input box.
- The header and payload are decoded the moment you paste — no button to press, no waiting.
- Read the formatted JSON for each part on its own. The signing algorithm from the header is shown at a glance.
- Check the timestamp summary:
exp,iat, andnbfare converted from raw Unix seconds into readable local dates, and the tool tells you whether the token is currently valid, already expired, or not yet active. - Tap Copy on the header or payload to grab it, then move on. Optionally paste an HMAC secret to verify the signature locally.
The whole flow is built so you get the answer in one second and close the tab.
The structure behind it: header.payload.signature
A signed JWT is three Base64URL segments separated by dots. The first segment is the
header, a small JSON object that declares the signing algorithm (the
alg field, such as HS256 or RS256) and the token type
(typ, usually JWT). The second segment is the payload,
a JSON object of claims: registered claims like iss (issuer), sub
(subject), exp (expiry), iat (issued at), and nbf
(not before), plus any custom data the issuer added, such as a user id or role. The third
segment is the signature, a cryptographic value computed over the first two
segments using a secret or private key.
Decoding is straightforward and requires no secret: the tool splits the string on the dots, converts each segment from Base64URL back to bytes, and parses the bytes as JSON. This is why a JWT is not a secret container — anyone holding the token can read its claims. The signature is what stops tampering, not the encoding. Verifying that signature is a separate, optional step that needs the key; this tool does HMAC verification in your browser if you supply the secret.
Examples
Reading a session token. You paste a token from a failed API request. The
payload decodes to show "exp": 1700000000, which the tool renders as a date in the
past and labels "Expired." Now you know the request failed because the session had timed out,
not because the credentials were wrong.
Checking an algorithm. A security review asks which algorithm your service
issues. You paste a sample token and the header shows "alg": "HS256", confirming a
symmetric HMAC signature rather than RSA.
Inspecting custom claims. Your front end is missing a permission. You decode
the token and see the payload has "role": "viewer" instead of
"editor", so the bug is in how the role was set at sign-in, not in the front end.
Common use cases
- Debugging authentication — see exactly why a token was rejected (expired, wrong issuer, missing claim).
- Reading expiry without math — turn
expandiatinto real dates instead of converting Unix seconds by hand. - Verifying which algorithm is in use — confirm a service signs with the algorithm you expect.
- Inspecting custom claims — check user ids, roles, scopes, or tenant ids embedded in the payload.
- Local signature checks — confirm an HMAC-signed token is authentic during testing without standing up a backend.
- Learning how JWTs work — see the header, payload, and signature structure laid out plainly.
Why use this one
Most online decoders are fine, but the safest place to inspect a token is one that never sends it anywhere. Here, the token, its claims, and any secret you type are decoded entirely in your browser; nothing is uploaded, logged, or stored. That is the whole point, because a JWT is frequently a live credential, and pasting it into a tool that ships it to a backend is a quiet security risk. On top of that, this decoder humanizes the timestamps for you and flags expiry instead of leaving raw Unix seconds on the screen, renders instantly with one-click copy for each part, and needs no signup. When you need to work with the raw encoding, hand the parts to the Base64 Encode / Decode tool; to tidy the payload further, use the JSON Formatter; and for query-string work, see URL Encode / Decode.
Frequently asked questions
Is my token safe — is anything uploaded to a server?
No. The JWT is split and Base64URL-decoded entirely inside your browser using JavaScript. The token, its claims, and any secret you enter for verification are never sent to, stored on, or seen by any server. Because a JWT is often a live credential, this matters: you can safely inspect a real production token here.
Does this tool verify the token's signature?
Decoding and signature verification are separate steps. By default the tool only decodes the header and payload so you can read them — anyone can do that, since a JWT is just Base64URL-encoded JSON, not encrypted. If you paste an HMAC secret (for HS256, HS384, or HS512 tokens), the tool will additionally recompute the signature in your browser and tell you whether it matches.
Why does my decoded token show as expired?
The payload's exp claim is a Unix timestamp (seconds since 1970) marking when the token stops being valid. The tool converts it to a readable local date and compares it to the current time; if exp is in the past, the token is flagged expired. An nbf (not-before) claim in the future is flagged as not yet valid.
Can I decode an encrypted JWT (JWE)?
No. This tool decodes signed JSON Web Tokens (JWS), which is the common format used for authentication. Encrypted tokens (JWE) have five dot-separated parts instead of three and their payload is ciphertext, so it cannot be read without the decryption key. If your input has five segments, it is a JWE and will not decode here.
What do the three parts of a JWT mean?
A JWT has three Base64URL-encoded parts joined by dots: header.payload.signature. The header states the signing algorithm and token type, the payload holds the claims (such as the user id, issuer, and expiry), and the signature is a cryptographic check that the first two parts were not tampered with. This tool decodes the header and payload and shows the algorithm from the header.