JWT Token Decoder
Decode JWT tokens and detect PII in claims
Outcome
Decode a JWT safely, identify sensitive claims, and decide whether the token should be redacted, rotated, or kept out of shared material.
Your progress
Mark each step as you complete it. This is saved only in this browser.
0 / 3 steps complete
Before you start
Visual frame
Review asset
JWT decoder storyboard
Synthetic JWT frame only. It uses fake token parts and avoids asking users to paste live bearer tokens into support.
Synthetic frame
JWT input
Do not use a live bearer token for learning.
JWT inspection frame
A token-safety flow that decodes structure for understanding while keeping raw tokens out of support and public channels.
Guided steps
Follow the task, then check the result.
Start with a safe or authorised token
A JWT can contain sensitive claims even when it looks like harmless text. Use a synthetic token for learning and treat real tokens as secrets unless your policy says otherwise.
Review claims before sharing
Look for email, subject, tenant, role, scope, group, organisation, IP, session, expiry, and custom claims. Decide what must be redacted before pasting the decoded payload anywhere.
Share only sanitised token context
When asking for help, share the claim names, redacted values, expiry state, or error message. Do not share the raw token by default.
Branch questions
Do the decoded claims contain names, emails, roles, tenant IDs, or scopes?
Was the raw token pasted into logs, code, or a public issue?
Completion check
Support boundary
Support can use by default
- Claim names and redacted example values.
- Error category such as malformed token, expired token, or unsafe claim.
- No raw JWT by default.
- Intent ID
- Article slug
- App route
- Browser and viewport
Requires your consent
- User-written description
- Email address
- Explicit attachment
- Redacted sample
- Support bundle previewed to the user
Not collected by default
- Raw original document text
- Full local file paths
- Pasted private content
- Unmasked screenshots
- Replay capture
Safe support summary
Copy a scrubbed handoff.
Redactorr KB support summary Article: /knowledge-base/jwt-decoder Selected issue: The decoder cannot parse a token shape you expected it to parse. Playbook progress: 0/3 steps marked complete Safe context to include: - Claim names and redacted example values. - Error category such as malformed token, expired token, or unsafe claim. - No raw JWT by default. - Intent ID - Article slug - App route - Browser and viewport Requires explicit consent: - User-written description - Email address - Explicit attachment - Redacted sample - Support bundle previewed to the user Do not include by default: - Raw original document text - Full local file paths - Pasted private content - Unmasked screenshots - Replay capture User note: - Describe the step and symptom without pasting raw document text, secrets, files, or restoration material.
Article details
JWT Decoder: Peel Back the Layers
JSON Web Tokens (JWTs) are everywhere in modern apps. They're used for authentication, authorisation, and passing data between services. But what's actually inside them?
The JWT Decoder shows you what your tokens contain—and whether they're leaking sensitive information.
What's a JWT?
A JWT looks like random gibberish:
But it's actually three parts separated by dots: 1. Header: Token metadata (algorithm, type) 2. Payload: The actual claims (user data) 3. Signature: Cryptographic verification
The first two parts are just Base64-encoded JSON—anyone can decode them. The signature is what makes JWTs secure.
Why Decode?
Check what data you're exposing: JWTs are often passed in URLs, stored in localStorage, or sent over HTTP. If your JWT contains sensitive data like emails, phone numbers, or SSNs, that data is exposed to anyone who intercepts the token.
Debug authentication issues: When login isn't working, peek inside the JWT to see if claims are malformed, expired, or missing required fields.
Audit for compliance: Security audits often require proving that tokens don't contain PII (Personally Identifiable Information). The decoder flags any PII it finds.
What You'll See
After decoding, you get:
- Header: Algorithm used (HS256, RS256, etc.)
- Payload: All claims in the token
- Expiration: When the token expires
- PII Detection: Any sensitive data in claims (emails, phone numbers, etc.)
- Token Age: How long the token has been valid
Real-World Example
Bad JWT (contains PII):
Good JWT (no PII):
Your Tokens Stay Private
Decoding happens in your browser. Original tokens stay local during decoding.
Still stuck?
Copy a safe article handoff.
Start support with the article, the issue, and safe context. Raw document text, files, restoration material, and unredacted screenshots stay out unless you explicitly choose otherwise.
- Article slug
- Selected issue
- Screen name
- Action name
Redactorr support case Source: Article playbook: jwt-decoder Route: /knowledge-base/jwt-decoder Selected issue: The decoder cannot parse a token shape you expected it to parse. Safe context: - Claim names and redacted example values. - Error category such as malformed token, expired token, or unsafe claim. - No raw JWT by default. - Article slug - Selected issue - Screen name or article section - Action name - Browser and viewport Only include with explicit consent: - User-written description - Email address - Explicit attachment - Redacted sample - Support bundle previewed to the user Do not include by default: - Raw original document text - Full local file paths - Pasted private content - Unmasked screenshots - Replay capture - Hidden diagnostic uploads User note: - Describe what you tried and what happened. Do not paste raw document text, secrets, files, restoration material, or unredacted screenshots.
Support case builder
One case format, wherever you start.
This is the same support case shape used by diagnostics and article handoffs.
- Claim names and redacted example values.
- Error category such as malformed token, expired token, or unsafe claim.
- No raw JWT by default.
- Article slug
- Selected issue
- Screen name or article section
Private material belongs behind an explicit consent step, not in the initial case.
6 default exclusions