Quick answer
A JWT is commonly written as header.payload.signature. The header describes token metadata, the payload contains claims, and the signature is used by proper verification logic to check authenticity. Use the JWT Decoder to inspect a dummy or redacted token, but do not treat decoded output as proof that the token is valid or trusted.
The three JWT parts in plain language
A JSON Web Token is often compact because each part is represented as URL-safe text and separated by dots. That compact shape is useful in headers and API examples, but it can hide the fact that the header and payload are usually readable after decoding.
| JWT part | What it usually contains | What to remember |
|---|---|---|
| Header | {"alg":"HS256","typ":"JWT"} | Metadata such as token type and signing algorithm. Readable metadata does not prove trust. |
| Payload | {"sub":"sample-user","iss":"demo-app","aud":"demo-api","exp":1893456000} | Claims about the subject, issuer, audience, or expiry. Payload data may be readable and should not contain secrets. |
| Signature | signature-part | Used by real verification workflows to detect tampering and confirm expected signing rules. Decoding alone does not verify it. |
Safe dummy JWT-like example
For learning, use a dummy or redacted token shape rather than a live production token. A simplified example may look like this:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJzYW1wbGUtdXNlciIsImlzcyI6ImRlbW8tYXBwIiwiYXVkIjoiZGVtby1hcGkiLCJleHAiOjE4OTM0NTYwMDB9.signature-partAfter decoding, the header and payload become readable JSON concepts. The JSON Formatter can help inspect decoded JSON structure, and the Base64 Encoder Decoder can help explain reversible text representation. Neither step makes a JWT trusted.
Common reasons to learn JWT parts
- Learning how JWT structure works without using live credentials.
- Understanding header algorithms and token type at a conceptual level.
- Reading safe payload claims such as exp, iat, iss, aud, and sub.
- Explaining why signature verification matters in real authentication systems.
- Debugging non-sensitive development tokens after redaction.
- Teaching the difference between decode-only inspection and verified trust.
Mini decision rule
- Use JWT Decoder to inspect token structure and readable claims.
- Do not treat decoding as verification or proof of authenticity.
- Use proper server-side verification when authenticity, audience, issuer, expiration, or access decisions matter.
- Use JSON Formatter when decoded JSON needs clearer formatting.
- Use Base64 Encoder Decoder for general Base64 learning, not JWT trust decisions.
- Do not paste live sensitive JWTs, API keys, session tokens, or production secrets into online tools.
Best practices for JWT inspection
- Use dummy, expired, or redacted tokens whenever possible.
- Never assume decode means verify.
- Do not put secrets in JWT payloads because payload data may be readable.
- Avoid pasting live production tokens into online tools.
- Verify signatures with trusted backend or security workflows.
- Treat decoded claims as readable data, not proof of authenticity.
Trust and privacy note
If you need to make an authentication decision, use your application’s proper verification path. A readable payload can help you understand a token, but it should not be accepted as trusted data by itself.
JWT Header Payload Signature Explained FAQ
What are the three parts of a JWT?
A typical JWT has three dot-separated parts: header, payload, and signature. The header describes metadata, the payload contains claims, and the signature is used by verification logic.
What is inside a JWT header?
The header usually includes token metadata such as the token type and the signing algorithm. Reading the header does not prove the token is trusted.
What is inside a JWT payload?
The payload contains claims such as subject, issuer, audience, issued-at time, or expiration. Payload data is often readable after decoding, so it should not contain secrets.
What does a JWT signature do?
The signature is used by proper verification workflows to check whether the token matches expected signing rules and has not been tampered with.
Does decoding a JWT verify the signature?
No. Decoding only makes token parts readable. Signature verification is a separate security step.
Should JWT payloads contain secrets?
No. JWT payloads may be readable by anyone who has the token, so passwords, private keys, credentials, and sensitive secrets do not belong in ordinary readable payload claims.