JWT Payload Viewer
JWT Payload Viewer reads the second compact-token segment and pretty-prints its JSON claims. It does not verify the signature, decrypt an encrypted JWT, validate claim types, or check issuer, audience, expiration, not-before time, or revocation. Decoded claims remain untrusted and may contain personal or sensitive data.
Runs locally — files stay on your deviceCan a decoded JWT payload be trusted?
No. Decoding is reversible text processing; claims become trustworthy only after correct cryptographic and semantic validation.
JWT claims are assertions, not proof by themselves
Payload fields can include registered claims such as iss, sub, aud, exp, nbf, iat, and jti plus application claims. Their meaning depends on the issuer and verification policy.
How it works
The tool selects the second dot-separated segment, converts Base64url notation, decodes the bytes, parses JSON, and displays the result.
Key concepts
Signature and claims both need validation
A valid signature alone does not prove the issuer, audience, time window, or token type is acceptable.
Visibility is not confidentiality
Base64url text can be decoded by anyone who sees the token.
When to use it
- Inspect a synthetic token during integration debugging.
- Read registered and private claim names.
- Explain that signed payloads are usually visible.
When not to use it
- Do not make authorization decisions from the display.
- Do not paste active session tokens unnecessarily.
- Do not assume every JWT payload is encrypted or private.
Worked examples
Expiration claim
- Input
Payload with exp: 1893456000- Expected output
JSON number is visible
This page does not decide whether it is valid.
Audience array
- Input
Payload with aud list- Expected output
Array displayed
The consuming service must verify intended audience.
Tampered payload
- Input
Edited second segment- Expected output
Edited JSON may still decode
Only signature verification would detect unauthorized alteration.
Common mistakes
Trusting visible roles
An attacker can edit an unverified payload. Correction: Verify before authorization.
Putting secrets in claims
Signed JWTs are often readable. Correction: Keep sensitive data out or use an appropriate encrypted design.
Checking exp only
Issuer, audience, nbf, token type, and other policy can also matter. Correction: Use a complete validation profile.
Best practices
- Use vetted verification libraries.
- Minimize claims and token lifetime.
- Validate issuer, audience, algorithm, key, token type, and relevant times.
Related operations and differences
JWT Header Viewer
Choose JWT Header Viewer when you need to decode a JWT header without verifying its signature.; use JWT Payload Viewer specifically for jwt payload.
Basic Auth Header Generator
Choose Basic Auth Header Generator when you need to generate a Basic Authorization header locally.; use JWT Payload Viewer specifically for jwt payload.
HMAC Generator
Choose HMAC Generator when you need to create an HMAC using the browser Web Crypto API.; use JWT Payload Viewer specifically for jwt payload.
JWT Expiration Checker
Choose JWT Expiration Checker when you need to inspect the exp claim in a JWT.; use JWT Payload Viewer specifically for jwt payload.
Passphrase Generator
Choose Passphrase Generator when you need to generate a local random multi-word passphrase.; use JWT Payload Viewer specifically for jwt payload.
Password Entropy Calculator
Choose Password Entropy Calculator when you need to calculate estimated entropy from an assumed character pool.; use JWT Payload Viewer specifically for jwt payload.
Limitations and privacy
- Decoding only.
- No JWS verification or JWE decryption.
- No semantic, revocation, issuer, audience, or time validation.
The entered value is processed locally in this browser. Avoid using an untrusted device for real credentials or secrets.
Frequently asked questions
Does it verify roles or permissions?
No.
Can anyone read the payload?
For ordinary signed compact JWTs, yes.
Does it check exp?
No.
Can a tampered token still decode?
Yes.