Paste the compact token
Enter the familiar header.payload.signature form. A leading Bearer prefix and wrapped whitespace are removed automatically.
← Back to Xepoca1 2 3
Developer tool
JWT Decoder
Decode a JSON Web Token into its header, payload, standard claims, timestamps, and signature bytes. Inspect token structure instantly without sending credentials to a server.
🔒 100% private browser processing
Your JWT stays on your device. Xepoca does not upload, store, verify, or transmit the token.
JWT input
Paste a compact token or load one from a local text file.
Drop a token file here
TXT, JWT, TOKEN, LOG, or JSON · maximum 2 MB
Sample tokens
Decoding is not verification
Do not trust claims merely because they decode. A receiving application must verify the signature, algorithm, issuer, audience, and time constraints using trusted configuration.
Decoded token
Readable contents and structural analysis appear here.
🔑
Paste a JWT to decode it
The tool expects the common three-part compact form: header.payload.signature.
Inspect decoded claims
Review standard claims, readable timestamps, custom application data, algorithm metadata, and signature bytes.
Verify elsewhere
Use your application's trusted key material and validation rules to verify authenticity before relying on any claim.
What a JWT decoder can—and cannot—tell you
Readable token structure
A commonly used signed JWT is a compact JWS with three Base64URL segments. The first two segments normally contain JSON. Decoding reveals that JSON, but Base64URL is an encoding—not encryption.
Authenticity requires verification
A malicious party can create or edit a token that decodes perfectly. Production systems must restrict accepted algorithms, verify the signature with trusted keys, and validate issuer, audience, expiry, not-before time, and application-specific claims.
Registered JWT claims
iss
Issuer
sub
Subject
aud
Audience
exp
Expiration time
nbf
Not before
iat
Issued at
jti
JWT ID
Security checklist
- • Never place passwords, private keys, or unnecessary personal data inside a readable JWT payload.
- • Treat tokens as credentials and avoid sharing production tokens in tickets, chats, screenshots, or logs.
- • Do not select verification algorithms from untrusted token input alone.
- • Allow reasonable clock skew, but enforce expiration and not-before checks.
- • Rotate signing keys safely and use the key ID only as a lookup hint—not as proof of trust.
Related Xepoca tools
Frequently asked questions
Does decoding a JWT verify its signature?+
No. Decoding only transforms Base64URL segments into readable data. Verification requires trusted key material and strict validation of the declared algorithm and relevant claims.
Are JWTs encrypted?+
Usually not. Signed JWTs are commonly encoded and readable by anyone who receives them. Encrypted JWTs use JWE and have a different five-part compact structure, which this three-part JWT decoder does not process.
Why does the tool say my token is expired?+
The exp claim is a Unix timestamp in seconds. When it is at or before the browser's current time, the token is expired. A server may apply a small configured clock-skew allowance.
Can I paste a production access token here?+
Processing is local, but access tokens are sensitive credentials. Prefer test tokens whenever possible, keep production tokens out of screenshots and logs, and clear the input when finished.
What does alg=none mean?+
It declares an unsecured JWT with no digital signature. Such tokens should only be accepted in tightly controlled situations where the application explicitly permits them.