Understand this tool
Inspect a JWT without confusing decoding with trust
- What the concept means
- A JSON Web Token is a compact claims format defined by RFC 7519 and commonly protected with JOSE signing or encryption mechanisms.
- Why it exists
- Decode the readable header and payload of a three-part JSON Web Token in the browser.
- When to use it
- Inspecting token structure and time claims while debugging, using non-sensitive or fictional data.
- What the result means—and does not mean
- Readable JSON and time status do not prove the issuer, signature, audience, permissions, or authenticity.
JWT inside the JOSE family
JWT defines a set of claims carried in JSON. A common signed JWT is serialized as a JWS compact value: protected header, payload, and signature separated by periods. Encrypted JWTs use JWE and have a different five-part compact shape.
Registered claims include iss, sub, aud, exp, nbf, and iat. They are optional unless an application profile requires them. Time claims use NumericDate seconds from the Unix epoch, and real verifiers often allow a small clock-skew tolerance.
Decoding is intentionally easy
Header and payload use Base64URL so any recipient can read them. Confidential data does not belong in an ordinary signed JWT. Trust comes only after a verifier restricts acceptable algorithms, selects a trusted key, checks the signature, and enforces issuer, audience, time, and application rules.
Worked example
Decode a fictional, deliberately unverified token
The sample uses alg “none”, a placeholder signature, and historical time claims. It must never be used for authentication.
- Example input
- Header alg=none, typ=JWT; payload iat=1704067200, nbf=1704067200, exp=1704153600.
- Split the token at its two periods into three segments.
- Base64URL-decode the header and payload segments.
- Parse the decoded text as JSON.
- Interpret iat and nbf as 2024-01-01 UTC and exp as 2024-01-02 UTC, so the sample is now expired.
Example result: The header and payload are readable; the time claims are historical; authenticity remains completely unverified.
The signature text is only a placeholder. Decoding cannot establish trust or permissions.
Key concepts
Key concepts
- JWT
- A compact token format whose common signed form has header, payload, and signature segments.
- Base64URL
- A URL-safe text encoding used for JWT segments; it is not encryption.
- Header
- Metadata such as token type and the declared signing algorithm.
- Payload
- Claims carried by the token; they are readable and should not contain secrets.
- Signature
- Data a trusted verifier checks to detect modification and confirm the expected signing key.
- Claims
- Named statements such as subject, issuer, audience, and time values.
- iat, nbf, and exp
- Unix-second claims for issued-at, not-before, and expiration times.
- Signature verification
- Cryptographic validation performed with trusted algorithms, keys, and application rules; this page does not do it.
Method or process
How the process works
Decoding is intentionally easy
Header and payload use Base64URL so any recipient can read them. Confidential data does not belong in an ordinary signed JWT. Trust comes only after a verifier restricts acceptable algorithms, selects a trusted key, checks the signature, and enforces issuer, audience, time, and application rules.
Compare the concepts
Decoding is not verification
| Operation | What it can show | What it cannot prove |
|---|---|---|
| Decode | Readable header, payload, and time claims | Issuer, integrity, audience, or permission |
| Verify | Whether a trusted cryptographic and application policy accepts the token | That every downstream authorization decision is correct |
Common mistakes
Common mistakes
- Assuming readable claims are trustworthy.
- Assuming a declared algorithm means the signature was checked.
- Treating an unexpired token as fully valid and authorized.
Edge cases and limits
Edge cases and limits
- A JWT must have exactly three non-empty segments for this decoder.
- Invalid Base64URL or non-JSON segments cannot be decoded.
- Some tokens omit one or all time claims.
- Clock differences can affect boundary-time decisions in real systems.