JWT Decoder: Inspect Claims and Expiration

SecurityRuns in Your Browser (No Uploads)

Decode compact JSON Web Tokens locally to inspect the protected header, payload claims, signature bytes, and exp, nbf, and iat timestamps. Strict Base64URL and JSON checks expose malformed tokens, but no signature or claim is verified.

What to do next

Continue with a related workflow or open the next tool that usually follows this task.

How to Use This Tool

Paste a synthetic or redacted three-part JWT, with or without the Bearer prefix.

Decode it and review structural errors before reading any claim values.

Inspect the declared alg and kid, payload claims, signature byte count, and exp, nbf, and iat UTC details.

Read every warning, especially signature not verified, alg none, expired, not-yet-valid, future iat, critical headers, or imprecise numbers.

Copy or download the inspection for debugging, then verify the original token with a trusted server-side JWT library before making any decision.

When to Use This Tool

API authentication debugging

Compare issuer, audience, subject, scope, role, and time claims while investigating a 401 or 403 response.

OAuth and OpenID Connect integration

Inspect access-token or ID-token claim shape before checking the identity provider and backend verification configuration.

Token security review

Spot alg none, unexpected key identifiers, critical headers, sensitive payload data, and inconsistent NumericDate ordering during review.

Safe debugging documentation

Produce a readable, explicitly unverified JSON inspection from a synthetic token for tests, tickets, or documentation.

Common Mistakes

Treating decoded output as verified

The header and payload are attacker-controlled until a trusted library verifies the signature and enforces an algorithm policy, issuer, audience, and time rules. Readable output is not proof of authenticity.

Putting secrets in payload claims

JWT payloads are commonly signed and encoded, not encrypted. Passwords, API keys, session secrets, and unnecessary personal data remain readable to anyone holding the token.

Checking only expiration

A future exp value does not make a token acceptable. nbf, iat, iss, aud, key selection, revocation, and application-specific claims can still cause rejection.

Trusting the declared algorithm

Do not let an unverified alg header choose a permissive verification path. Configure the allowed algorithms and trusted keys in the verifier independently of token input.

Confusing JWS and JWE compact forms

A five-part JWE is encrypted and needs the intended decryption key and algorithm handling. It cannot be inspected as a three-part signed JWS payload.

Examples

Inspect UTF-8 claims and NumericDate values

This synthetic RS256 token includes Korean UTF-8 text and future time claims. The signature text is deliberately a demo value, so the output remains untrusted.

Input
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRlbW8tMjAyNi0wNyJ9.eyJzdWIiOiJkZW1vX3VzZXJfNDIiLCJuYW1lIjoi6rCA656MIiwic2NvcGUiOiJyZXBvcnRzOnJlYWQiLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS50ZXN0IiwiYXVkIjoicmVwb3J0cy1hcGkiLCJpYXQiOjE3ODQwNzM2MDAsIm5iZiI6MTc4NDA3MzYwMCwiZXhwIjoxODkzNDU2MDAwfQ.ZGVtby1zaWduYXR1cmUtbm90LXZlcmlmaWVk
Output
{
  "header": { "alg": "RS256", "typ": "JWT", "kid": "demo-2026-07" },
  "payload": { "sub": "demo_user_42", "name": "가람", "exp": 1893456000 },
  "inspection": { "signatureVerified": false }
}

Recognize an unsecured alg none token

An unsecured token declares alg none and must have an empty third segment. The decoder displays an explicit integrity warning rather than calling it valid.

Input
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZW1vIiwiZXhwIjoxNzAwMDAwMDAwfQ.
Output
{
  "algorithm": "none",
  "signature": { "present": false, "verified": false },
  "expirationStatus": "expired"
}

Strict decoding boundaries and trust model

A compact signed JWT uses three dot-separated segments: protected header, payload, and signature. The first two segments are unpadded Base64URL-encoded UTF-8 JSON objects; their contents are readable without any key.

The decoder requires canonical Base64URL characters, valid UTF-8, one JSON object per header and payload, a non-empty alg string, and an appropriate empty or non-empty signature segment. Duplicate keys are rejected because different parsers can otherwise interpret the same token differently.

exp, nbf, and iat are inspected as finite NumericDate seconds. UTC timestamps and relative seconds are added, while expired, not-yet-valid, future-issued, malformed, and impossible ordering conditions remain separate warnings instead of one replacing another.

The signature segment is decoded only to report its byte count. No secret, public key, JWKS lookup, MAC comparison, issuer check, audience check, revocation check, or application authorization rule runs in this browser tool.

Input is limited to 100KB, JSON nesting to 64 levels, node count to 50,000, and formatted output to 512KB. Five-part JWE input is identified separately because encrypted tokens require decryption rather than payload decoding.

Frequently Asked Questions

Does this tool verify a JWT signature?

No. The tool only decodes and inspects compact token data. Verify the signature with trusted keys and enforce allowed algorithms, issuer, audience, time claims, and application policy on a trusted server.

Can it tell whether a token is valid or expired?

It reports whether exp is absent, malformed, already passed, or still in the future relative to the browser clock. That is only an observation; it does not prove the signature, issuer, audience, clock skew policy, or token acceptability.

How are JWT time claims displayed?

exp, nbf, and iat are NumericDate values measured in seconds since the Unix epoch. The output adds UTC timestamps and relative seconds while retaining the original claim value.

Can this decode encrypted JWE tokens?

A three-part compact JWS can be decoded. A five-part compact JWE is encrypted and is rejected with a specific message because decryption requires keys and algorithm policy.

Does the JWT leave my browser?

Decoding runs in the browser and the tool does not upload the token. A real access token can still grant permissions or expose personal data, so use a redacted or synthetic token whenever possible.

Why is a token rejected as malformed Base64URL or JSON?

Strict unpadded Base64URL accepts letters, digits, hyphen, and underscore. Standard Base64 characters such as plus, slash, padding equals signs, internal whitespace, invalid UTF-8, malformed JSON, and duplicate keys are rejected.

What input and structure limits apply?

The decoder permits up to 100KB of input and bounds JSON depth, node count, and output size. These limits keep malformed or unexpectedly large tokens from consuming excessive browser resources.

How This Tool Was Verified

Maintained and tested by Reviewed

Method: The review loaded the unmodified “JWT payload with expired access” sample into JWT Decoder: Inspect Claims and Expiration. We exercised the path from “Redact sensitive values first” to “Verify elsewhere before trusting it”, checked the displayed or downloaded result against the example, and separately examined “Assuming decoded means verified” and “Pasting the whole Authorization header”.

Expected result: The payload exposed sub, scope, aud, and exp exactly as encoded, while the result continued to label the claims unverified and the sample expiration as past.

Sources and standards

Open the tested workflow

Related workflow guides

Use these focused guides when you need a practical workflow before opening the tool.

Workflow guide

Decode a Base64 API payload without corrupting bytes

Use this repeatable workflow for encoded JSON fields, webhook metadata, headers, cookies, and logs. It validates the alphabet and padding before decoding, preserves binary bytes for download, and keeps Base64 separate from encryption or signature verification.

Workflow guide

Verify a file checksum with SHA-256

Use the local file mode and explicit checksum comparison to confirm byte equality before trusting a release archive, backup, or installer. A match does not certify the publisher or prove that the file is malware-free.

Workflow guide

Decode a JWT safely before debugging authentication

Use this workflow when a login, API request, or permission check fails and you need to inspect token claims before changing auth code.

Workflow guide

Build a UTC incident timeline from Unix timestamps

Use this workflow after you have identified the timestamp fields and need to order cross-system events, separate event time from ingest time, account for clock skew, and explain the result without overstating causality.

Workflow guide

Check JWT expiration and not-before timestamps

Use this workflow to determine whether a request occurred before nbf, at or after exp, or inside the stated token window, while documenting clock-skew policy and removing the raw token from shared evidence.

Workflow guide

Diagnose and recover one double-encoded query value

Use this workflow when a callback, webhook, proxy, SDK, or copied link contains `%252F`, `%2520`, `%253A`, or another sign that a percent sign was encoded again.

Related Tools

Continue with another maintained workflow

Browse All Tools