Developer Tools

JWT Decoder

Inspect the readable JSON inside a compact JWT/JWS token. This decoder reveals the declared header and payload and converts embedded date numbers into UTC. It does not authenticate a token or decide whether a service should accept it.

Free online tool

Loading tool…

Decoded claims are unverified input. This tool does not check a signature, key, issuer, audience, algorithm policy, revocation, or whether a token is accepted by any service.

Header · unverified

{
  "alg": "none",
  "typ": "JWT"
}

Signature segment: 0 bytes. The header declares alg: none (unsecured).

Payload · unverified

{
  "sub": "demo-user",
  "iss": "https://example.com",
  "iat": 1700000000,
  "exp": 1700003600
}

Embedded dates

ClaimLiteral valueUTC interpretation
iat17000000002023-11-14T22:13:20.000Z
exp17000036002023-11-14T23:13:20.000Z

NumericDate values count seconds from the Unix epoch. These are date conversions only; they do not establish token validity or expiry acceptance.

Runs locally with no token storage or URL sharing. A signed token is usually readable, not encrypted. Avoid pasting production credentials; use a synthetic or revoked token when possible. JSON numbers use JavaScript number precision; duplicate keys keep the last value.

No token is stored in browser storage or a shareable URL by this tool. Copied or downloaded JSON may still contain credentials or personal information.

GET STARTED

How to use the JWT Decoder

  1. 01

    Paste a three-part compact token, or keep the synthetic unsecured example.

  2. 02

    Read the unverified header and payload. Inspect iat, nbf, and exp as literal claims and UTC conversions.

  3. 03

    Copy or download the decoded JSON, then clear the token when finished.

Examples

Synthetic unsecured token

The example declares alg: none and an invented demo-user subject. It has no signature and is suitable for learning the compact structure.

Read a NumericDate

The number 1700000000 means 2023-11-14T22:13:20.000Z. JWT dates are seconds, rather than JavaScript’s usual milliseconds.

Recognize encrypted input

A compact JWE normally has five segments. This tool reports that encrypted input is unsupported rather than pretending the ciphertext is readable JSON.

Decoding and verification answer different questions

Base64url decoding only recovers bytes. A trustworthy verifier also needs an allowed algorithm, the right key, issuer and audience rules, time validation, and any application-specific policy. A header that says HS256 does not prove that a signature was checked.

Reading time claims

iat describes an asserted issue time, nbf an asserted earliest use time, and exp an asserted expiration time. This tool only formats their numeric values. It deliberately makes no accepted, expired, active, or trustworthy judgment; those decisions depend on verified claims and the receiving system’s clock and policy.

JSON and encoding boundaries

The input is capped at 32,768 characters. Header and payload must be unpadded base64url containing UTF-8 JSON objects. JavaScript JSON parsing retains the last duplicate property and can round integers beyond its exact range; numbers that overflow to infinity are rejected. Treat this view as an inspection aid, not a forensic byte-preserving parser.

What to know

  • Three-part readable JWS tokens only; no decryption, signature verification, claims validation, or revocation check.

Common questions

Can someone read a signed token?

Usually yes. A JWS signature protects integrity when correctly verified; it does not conceal its header or payload.

Do I need to enter a signing secret?

No. There is no key field because the tool does not perform signature verification. Never add signing secrets to the token input.

Can a displayed expiry date prove a token is invalid?

No. The displayed value is unverified data and the tool does not evaluate an application’s acceptance rules.

Sources & references