What are JWT payload claims?

Claims are statements about the user or session, encoded as JSON. Standard claims include sub (subject), exp (expiry), iat (issued at), iss (issuer), and aud (audience). Applications add any custom claims they need.

Are payload claims encrypted?

Payloads are Base64URL-encoded, not encrypted. Anyone with the token can read every claim. Avoid storing passwords or full card numbers in a JWT payload unless you use JWE (encrypted JWT).

How do I read the exp claim?

The exp claim is a Unix timestamp (seconds since 1970-01-01 UTC). The decoder shows it as a UTC date and time and tells you whether the token has expired.

Is the token sent to a server?

All decoding runs in your browser using standard JavaScript. Our servers are not involved at any point.

JWT Payload Decoder

Focus on the payload (claims) section of a JSON Web Token, the part that carries the actual data: user ID, roles, expiry time, and any custom application claims. Paste your JWT and the payload appears immediately. All decoding runs in your browser.

JWT token

⚠ Signature not verified, client-side only

VIEW

Runs entirely in your browser

How it works

A JWT consists of three Base64URL-encoded parts separated by dots. The tool splits the token, fixes URL-safe base64 encoding (replacing - with + and _ with /), pads to a multiple of 4 characters, then decodes the header and payload with atob() and parses them with JSON.parse(). The signature is not decoded. All of this runs in your browser. Our servers are not involved.

Processing runs in your browser

Your JWT is decoded entirely in your browser. Our servers are not involved at any point. Treat tokens as sensitive credentials and avoid pasting production tokens in shared or public environments. You can check this yourself in your browser's DevTools Network tab.

Technical specification

JSON Web Token (JWT) is defined in RFC 7519 (IETF, 2015). A JWT consists of three Base64url-encoded sections separated by .: header, payload, and signature. Base64url encoding is defined in RFC 4648 §5, which substitutes + with - and / with _ and omits padding, making it safe for use in URLs without percent-encoding. Signed JWTs (JWS) are specified separately in RFC 7515.

Structure: header.payload.signature (3 Base64url parts)
Standards: RFC 7519 (JWT), RFC 7515 (JWS), RFC 4648 (Base64url)
Header claims: alg (algorithm), typ (token type)
Common payload claims: sub, iss, exp, iat, aud

Related operations

To inspect the raw Base64 segments of a token, try Base64. For verifying the signing input by hash, use the hash generator. To pretty-print decoded payloads, see the JSON formatter.

Frequently asked questions

What are JWT payload claims?: Claims are statements about the user or session, encoded as JSON. Standard claims include sub (subject), exp (expiry), iat (issued at), iss (issuer), and aud (audience). Applications add any custom claims they need.
Are payload claims encrypted?: Payloads are Base64URL-encoded, not encrypted. Anyone with the token can read every claim. Avoid storing passwords or full card numbers in a JWT payload unless you use JWE (encrypted JWT).
How do I read the exp claim?: The exp claim is a Unix timestamp (seconds since 1970-01-01 UTC). The decoder shows it as a UTC date and time and tells you whether the token has expired.
Is the token sent to a server?: All decoding runs in your browser using standard JavaScript. Our servers are not involved at any point.

Last reviewed September 30, 2026

Other pages for this tool

Related tools

Background reading: Complete guide to developer tools