What Is a JWT? Header, Payload, Signature and Decoding

JWT stands for JSON Web Token. It is a compact, text-based way to pass a set of claims, small pieces of information, between systems. JWTs are common in web authentication and authorization, but they are often misunderstood. In particular, being able to read a token is not the same as trusting it.

This guide explains how a JWT is structured, what each part contains, and why decoding a token is different from verifying it.

JWT structure

A JWT has three parts, separated by dots:

header.payload.signature

Written out, a token looks like three encoded segments in the form xxxxx.yyyyy.zzzzz. The header and payload are encoded pieces of JSON, and the signature is used to check the token when the right key is available.

JWT header

The header describes the token. It commonly includes:

alg, the algorithm intended for the signature
typ, the token type, often JWT
kid, an optional key identifier in some tokens

Not every token contains the same header fields, and the presence of a field does not by itself mean the token is trustworthy.

JWT payload

The payload carries the claims. Claims fall into three groups: registered claims defined by the standard, public claims, and private claims agreed between parties. Common registered claims include:

sub, the subject the token is about
iss, the issuer that created the token
aud, the intended audience
exp, the expiration time
iat, the time the token was issued
nbf, a time before which the token is not valid

Payload claims are readable by anyone once the segment is Base64URL-decoded. A signed JWT is not secret, so never place passwords or confidential data in an ordinary JWT payload.

JWT signature

The signature lets a recipient check the token's integrity and authenticity, but only when it is verified with the correct key and algorithm. This is the part people most often misunderstand.

Decoding does not verify the signature.
A modified or forged token can still be decoded and will still display header and payload values.
Verification must happen in trusted application code or a trusted server environment, using the expected key and algorithm.

Base64URL encoding

The header and payload are encoded with Base64URL, a URL-safe variant of Base64.
Base64URL differs from regular Base64: the characters + and / are replaced by - and _.
Padding characters may be omitted.

Base64URL is an encoding, not encryption. For a full explanation of the difference, see Base64 encoding vs encryption.

Is a JWT encrypted?

An ordinary signed JWT is not encrypted; its header and payload can be decoded by anyone.
Signing protects against undetected tampering when verified, but it does not hide the contents.
JWE (JSON Web Encryption) is a separate standard for encrypted tokens.
Because ordinary payloads are readable, do not store passwords or secrets in them.

Decoding versus verifying

How decoding a JWT differs from verifying it
Capability	Decode	Verify
Reads the header	Yes	Yes
Reads the payload	Yes	Yes
Checks the signature	No	Yes
Requires a key	No	Yes
Proves authenticity	No	Yes
Safe for debugging	Yes	Yes
Suitable for authorization decisions	No	Yes

How to decode a JWT with WebToolkit

The JWT Decoder reads a token's header and payload so you can inspect its claims during development. It decodes only; it does not verify the signature.

Paste a token into the decoder.
Review the decoded header and payload.
Read the claims, including any timestamps.
Note that the tool marks the signature as not verified.
Do not treat the decoded output as proof that the token is valid.

Important

The token is sent to the server to decode and is not intentionally saved, but you should still avoid pasting production access tokens, session tokens, or secrets into any online tool unless you understand the risk. Prefer sample or expired tokens for debugging.

Decode a JWT for debugging

Inspect the header and payload of a token. Decoding reads claims but does not verify the signature.

Open JWT Decoder

Common JWT claims

Several claims describe timing and context. The exp, iat, and nbf claims are usually Unix timestamps, which you can interpret with the Timestamp Converter.

exp, when the token expires
iat, when the token was issued
nbf, the earliest time the token is valid
iss, who issued the token
aud, who the token is intended for
sub, who or what the token is about

Common JWT mistakes

Assuming a token that decodes is automatically valid
Trusting the alg field from untrusted input without a verification policy
Placing sensitive data in the payload
Ignoring the expiration claim
Using weak or shared signing secrets
Storing long-lived tokens insecurely
Reaching for a JWT for every session without checking whether it fits the requirements

JWT troubleshooting checklist

Confirm the token has three dot-separated segments
Check that the header and payload decode as valid Base64URL
Inspect exp and nbf to rule out timing issues
Confirm the issuer and audience match what you expect
Verify the signature with the expected key in trusted code
Ensure the expected algorithm is enforced during verification
Do not trust any claim before verification

Frequently asked questions

Is JWT encrypted?

An ordinary signed JWT is not encrypted. Its header and payload can be decoded by anyone. Encryption of tokens is handled by the separate JWE standard.

Can anyone decode a JWT?

Yes. The header and payload use Base64URL, which is reversible without a key, so anyone with the token can read those parts.

Does decoding verify the signature?

No. Decoding only reads the header and payload. Verifying the signature requires the correct key and algorithm and must be done in trusted code.

What does exp mean?

exp is the expiration claim, usually a Unix timestamp. After that time, a correctly implemented verifier should reject the token.

Why does a JWT have three parts?

The three parts are the header, the payload, and the signature, separated by dots. The header and payload carry data, and the signature is used to verify the token.

Can I store passwords in a JWT?

No. A signed JWT payload is readable by anyone, so passwords and other secrets must never be placed in it.

What is the difference between JWT and JWE?

A typical JWT is signed but not encrypted, so its contents are readable. JWE is a separate standard that encrypts the token so its contents are not readable without the key.

Conclusion

A JWT carries readable claims protected by a signature, but only verification proves a token is genuine. Use decoding to inspect and debug tokens, keep secrets out of payloads, and always verify in trusted code before trusting a claim. For inspection during development, the JWT Decoder reads the header and payload without verifying the signature.

Related reading: URL encoding and decoding explained and how to fix common JSON syntax errors, since JWT payloads are JSON.

What Is a JWT and How Does JWT Decoding Work?