1
Paste the token
The tool splits its three Base64URL segments and displays Header and Payload JSON as plain text.
DEVELOP.03 JWT DECODER
JWT Decoder
Token input, Header, Payload, and time claims stay visible on the first screen. JSON and Claims share tabs, and HMAC verification appears only when the algorithm needs it.
Paste a JWT
Waiting for a token
Header
Payload
ClaimValueMeaning
Signature & time status
§ 01
How to inspect a JWT safely
2
Check time claims
Open the Claims view to see local dates and relative status for exp, nbf, and iat, including expired or not-yet-active states.
3
Verify when possible
For HS algorithms, enter the shared secret to verify locally. Successful decoding does not make a signature trustworthy.
§ 02
Readable does not mean trusted
A JWT has three dot-separated segments. Header names the algorithm and type, Payload carries claims, and Signature verifies that the first two segments have not changed. The first two are Base64URL encoded, so anyone can read them without a key.
A common debugging mistake is to see a plausible Payload and assume the token is valid. Real authorization must verify the signature, issuer, audience, time window, and an allowlist of acceptable algorithms on the server.
§ 03
Common registered claims
Claim
Meaning
What to check
issIssuer
Matches the expected identity service
subSubject / user
Identifies the intended principal
audAudience
Includes the current service
expExpiration
Current time is earlier than this value
nbfNot before
Current time is not earlier than this value
iatIssued at
Falls within a reasonable time window
jtiUnique token ID
Can support revocation and replay controls
§ 04
Frequently Asked Questions
Q1What is the difference between decoding and verifying a JWT?
Decoding only restores Base64URL text to JSON and requires no key. Verification uses the correct secret or public key to confirm that content is unmodified and from a trusted issuer.
Q2Is the payload encrypted?
In a normal JWT, Header and Payload are encoded, not encrypted. Do not place passwords, private keys, or other client-invisible secrets in them.
Q3What do exp, nbf, and iat mean?
exp is expiration time, nbf is the earliest valid time, and iat is issue time. They are normally Unix timestamps in seconds.
Q4Why are only HS algorithms verified here?
HS256, HS384, and HS512 use a clearly entered shared secret. RS and ES verification involves public-key formats and curve parameters, so this page keeps them decode-only rather than giving an incomplete security guarantee.
Q5Are tokens and secrets saved?
No. Decoding and HMAC verification happen only in current page memory, with no server upload or browser storage.