JWT Decoder & ValidatorSpecialized Version
🎟️

JWT Payload Decoder

Decode payload

JWT Payload Decoder

Decode the JWT payload to view all claims and data stored in the token. The payload contains the actual information the token conveys.

JWT Payload Structure

The payload is the second part of the JWT (between the dots) and contains claims:

``json { "sub": "1234567890", "name": "John Doe", "email": "john@example.com", "role": "admin", "iat": 1516239022, "exp": 1516242622 } `

Claim Types

| Category | Claims | Description | Registerediss, sub, aud, exp, nbf, iat, jtiStandard claims with defined meanings Publicname, email, pictureCommonly used claims (IANA registry) | Private | role, permissions, tenant_id | Application-specific claims |

Payload Decoder Implementation

`javascript function decodeJWTPayload(token) { const parts = token.split('.'); if (parts.length !== 3) { throw new Error('Invalid JWT format'); }

const payloadPart = parts[1];

// Base64URL decode const base64 = payloadPart.replace(/-/g, '+').replace(/_/g, '/'); const decoded = atob(base64); const payload = JSON.parse(decoded);

// Analyze claims const analysis = { raw: payload, registeredClaims: {}, customClaims: {}, timestamps: {} };

const registered = ['iss', 'sub', 'aud', 'exp', 'nbf', 'iat', 'jti'];

for (const [key, value] of Object.entries(payload)) { if (registered.includes(key)) { analysis.registeredClaims[key] = value; // Convert timestamps to readable dates if (['exp', 'nbf', 'iat'].includes(key)) { analysis.timestamps[key] = new Date(value * 1000).toISOString(); } } else { analysis.customClaims[key] = value; } }

return analysis; } ``

Registered Claims Reference

| Claim | Name | Purpose | issIssuerIdentifies token creator subSubjectIdentifies the user/entity audAudienceIntended recipients expExpirationWhen token becomes invalid nbfNot BeforeWhen token becomes valid iatIssued AtWhen token was created | jti | JWT ID | Unique identifier for token |

Best Practices

  • Keep payload small (affects token size)
  • Never store sensitive data (passwords, secrets)
  • Use registered claims when appropriate
  • Include only necessary information

Frequently Asked Questions

What should I store in a JWT payload?

Store only what's needed for authentication/authorization: user ID (sub), roles/permissions, email, name. Don't store passwords, sensitive data, or large objects. Remember: payload is encoded, not encrypted—anyone with the token can read it. Keep it minimal to reduce token size.

Is the JWT payload encrypted?

No, standard JWTs (JWS) are signed but not encrypted. The payload is Base64URL-encoded—anyone can decode and read it. For encrypted payloads, use JWE (JSON Web Encryption). Even with JWE, don't store highly sensitive data in tokens.

What is the difference between sub and user_id?

sub (subject) is a registered claim with a standard meaning—the principal/user the token represents. user_id is a custom claim with no standard meaning. Use sub when possible as it's understood by JWT libraries and tools. The value should uniquely identify the user.

Related Tools

Explore other tools you might find useful:

Related Calculators