How JWT Decoding Works
Paste a compact signed JWT to inspect its Base64URL-encoded header and payload. Decoding is a local inspection step. Treat every displayed claim as unverified until a trusted implementation validates the signature and policy.
JWT Header, Payload and Signature
A common signed JWT has header, payload and signature segments separated by dots. The header describes token metadata, while the payload contains claims. An encrypted token has a different structure and cannot be decrypted by this decoder.
Reading Standard JWT Claims
Claims such as iss, sub and aud identify issuer, subject and audience. Their meaning depends on the application. Never grant access merely because a decoded payload contains a role or identity field.
JWT Expiration and Timestamps
The exp, iat and nbf claims use NumericDate seconds. Compare them with the intended clock and account for permitted skew in your authentication implementation. Use the timestamp converter for an independent human-readable date.
Decoding Is Not Signature Verification
A readable token is not necessarily authentic. Verification needs a trusted key, an allowed algorithm and checks on issuer, audience and time claims. The phrase JWT decrypt does not describe inspecting an ordinary signed, encoded JWT.
More examples and technical details
Anatomy of a JSON Web Token
A JWT is a compact, self-contained credential defined by RFC 7519. It is three Base64URL encoded segments joined by dots, and the format is designed so that a receiver can validate and read it without a database lookup. Nothing in it is encrypted: the first two segments are plain JSON wearing a very thin disguise.
- Header. Metadata about the token itself, principally alg (the signing algorithm) and typ (normally JWT). It may also carry kid, a key identifier telling the verifier which key to use.
- Payload. The claims, a JSON object of statements about the subject plus whatever the application needs.
- Signature. A cryptographic value computed over the first two segments and a key. It proves the token has not been altered.
Worked Example: Splitting a Token
Take the token above and decode each segment independently. Note that the signature is raw bytes, not text, so decoding it produces unreadable output. That is expected.
The segments use Base64URL, so dash stands in for plus, underscore for slash, and the trailing equals padding is stripped. That is why pasting a segment into a strict standard Base64 decoder sometimes fails on length.
Registered Claims
Seven claim names are registered by the specification. Everything else is either a public claim from the IANA registry or a private claim agreed between the issuer and consumer, such as email, scope, roles, or tenant_id.
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Identifies the party that created and signed the token. |
| sub | Subject | The principal the token is about, usually a user id. |
| aud | Audience | The recipients the token is intended for. Reject if you are not listed. |
| exp | Expiration time | Unix timestamp after which the token must be rejected. |
| nbf | Not before | Unix timestamp before which the token must be rejected. |
| iat | Issued at | Unix timestamp recording when the token was created. |
| jti | JWT ID | Unique identifier, useful for replay detection and revocation lists. |
All three time claims are seconds since the Unix epoch, not milliseconds. Converting them in JavaScript requires multiplying by 1000 before constructing a Date, and forgetting that produces expiry dates in 1970.
HS256 vs RS256
The alg header names the algorithm used to produce the signature. Two dominate real deployments, and the difference is about who needs to hold which key.
- HS256 (HMAC with SHA-256). Symmetric. One shared secret both signs and verifies. Fast and simple, but every service that verifies a token can also mint one, so it suits a single application that issues tokens to itself.
- RS256 (RSA signature with SHA-256). Asymmetric. A private key signs, a widely published public key verifies. Verifiers can never forge tokens, which is what makes it the standard choice for identity providers, OpenID Connect, and any multi-service architecture. ES256 offers the same property using elliptic curves with much smaller keys.
A verifier must decide which algorithm it accepts before it looks at the token, never after. Trusting the alg field in the header is the root of a well known class of attacks.
JWT Security Essentials
- Never put secrets in the payload. It is encoded, not encrypted. Anyone holding the token can read every claim.
- Always verify the signature server-side with a key you configured, not one derived from the token.
- Reject alg set to none. The specification allows an unsecured token, and libraries that honoured it turned forgery into a one line attack.
- Pin the expected algorithm. If you expect RS256, do not let a token arrive claiming HS256 and trick the verifier into using your public key as an HMAC secret.
- Always check exp, and nbf when present. Allow only a small clock skew, measured in seconds.
- Validate iss and aud. A valid token issued for a different service is not a valid token for yours.
- Keep lifetimes short. A JWT cannot be revoked by itself, so an access token should live for minutes and be refreshed, not for days.
Working on something related? Browse every free developer tool on the site, including a Base64 decoder, Base64 to JSON converter, JSON formatter, and hash generators. Everything runs entirely in your browser, so nothing you paste is ever uploaded.
Standards and references
Frequently asked questions
How do I decode a JWT token?
Paste the full signed token; the tool decodes its header and payload locally.
Can a JWT be decoded without the secret?
A signed JWT’s encoded content can be read without its signing secret. Encrypted JWTs require decryption keys and are not decoded this way.
Does decoding verify the JWT signature?
No. Decoding does not verify authenticity or authorize access.
What do exp, iat and nbf mean?
They represent expiration, issued-at and not-before times as seconds since the Unix epoch.
Is my token sent to a server?
No. Input is processed in this browser tab and is not uploaded by the tool. Copy and download are actions you control; ordinary page analytics do not receive tool input.