Generators Category Tool
JWT Decoder for inspecting Header, Payload, and expiration dates
Inspect JWT claims locally, understand each token part, and recognize the limits of decoding.
Includes
- Header, Payload, and Signature decoding
- iat and exp date parsing
- Token expiration status
- 100% browser-based execution
- Copy claims JSON
- Example token with three dot-separated segments
- Explicit notice that decoding does not validate the signature
Real-time inspection
Decode JWTs and review important claims with context
Paste a JWT to separate header, payload, and signature, review claims, and understand dates such as issuance and expiration. The content is processed in the browser, but real tokens must still be treated as sensitive information.
Paste a complete JWT in the header.payload.signature format.
Paste a complete JWT with three populated parts in a valid format.
Header
The decoded header will appear here.
Payload
The decoded payload will appear here.
Signature
The signature will appear here when all three segments can be read.
Summary
Fix the token to view its content.
Inspect JWT parts without relying on a backend
- 1. Paste a complete JWT in the standard three-part format.
- 2. The tool decodes the header and payload using Base64URL.
- 3. JSON claims and important dates are shown in a readable form.
- 4. Copy the payload for documentation, debugging, or technical analysis.
Analyze the token with context and care
- Use the decoder for inspection, not to establish trust in a token.
- Avoid exposing real production tokens in shared environments.
- Compare exp, iat, and nbf to understand session and expiration behavior.
- Validate the signature, issuer, and audience in a backend or controlled environment.
Resolve integration questions without treating the token as trusted
A JWT can look like an unreadable string when it appears in an HTTP header, log, or authentication response. This resource helps developers, students, and support teams understand a token's structure before debugging a flow.
- Quickly check which claims were emitted by a test environment.
- Compare iat, nbf, and exp dates while investigating sessions.
- Learn what is visible in a token without confusing readability with security validation.
How to use the decoder
- 1. Paste a complete JWT in the field, keeping all three segments separated by dots.
- 2. Check that the Header and Payload appear as JSON; a message appears if the format cannot be read.
- 3. Read the claims and converted dates to understand the token's context.
- 4. Use the example button to reproduce a fictional case and compare the result.
- 5. Clear the field when finished and do not reuse a real token in a shared environment.
What each segment represents
The compact format uses three Base64URL parts separated by dots. Header and Payload are decoded as JSON; the third segment is shown as text and is not verified.
Header
Contains token metadata, commonly the algorithm (alg) and type (typ).
It guides a validation library, but its values are still only received data.
Payload
Contains claims about the subject, issuer, audience, permissions, or lifetime.
A payload is not secret just because it is encoded: anyone with the token can read it.
Signature
The third segment is calculated by the issuer from the previous parts and a key.
This tool displays the segment for inspection but does not confirm integrity or authenticity.
Paste this fictional token and check the result
The example uses claims without personal data and a demonstration signature. Paste the token into the field above or use the example button to see exactly the values below.
Complete token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJuYW1lIjoiSHVibGFicyBEZW1vIiwiaWF0IjoxNzY3MjI1NjAwLCJleHAiOjE3NjcyMzI4MDAsInJvbGUiOiJyZWFkZXIifQ.signature-demo
Expected Header
{
"alg": "HS256",
"typ": "JWT"
}Expected Payload
{
"sub": "demo-user",
"name": "Hublabs Demo",
"iat": 1767225600,
"exp": 1767232800,
"role": "reader"
}Third segment
signature-demo
The value signature-demo is not a verifiable cryptographic signature. It demonstrates that the decoder separates and displays the third segment without claiming that the token is legitimate.
Decoding is not validation
Decoding does not validate the token's signature, authenticity, authorization, or security.
- It does not confirm that the signature matches the expected key or that the content remained intact.
- It does not prove that the token was issued by the expected party or is still authorized.
- It does not replace issuer, audience, expiration, and permission checks in a backend.
- It does not make exposed claims trustworthy, private, or secure.
Prefer fictional or sanitized tokens
Even with local browser processing, a token can grant access, reveal identifiers, or appear in history, the clipboard, and support tools. Do not paste production credentials; revoke a token if it is exposed.
Frequently asked JWT questions
Does decoding a JWT verify its signature?
No. Decoding only reveals the header and payload; it does not confirm authenticity or integrity. The signature must be verified with the correct key and procedure in a trusted environment.
What is the difference between the Header, Payload, and signature?
The Header describes metadata such as the algorithm and type; the Payload carries claims; the signature is the third segment used to check integrity when the right library and key are applied.
Is a JWT payload encrypted?
Not necessarily. In a typical JWT, the Header and Payload are Base64URL-encoded rather than encrypted, so anyone with the token can try to read them.
Can I paste a real token here?
Prefer a fictional or sanitized example. Real tokens may contain identifiers and permissions or grant access; do not share them in tools, tickets, history, or clipboards without authorization.
Does the tool send the JWT to a server?
This page's code decodes the content in the browser and does not need to send the token to a backend to show the results. That does not remove local risks such as history, copying, or browser extensions.