Skip to content
Orbilyra
Security & TokensAvailableFreeRuns locally

JWT Decoder

Decode JWT headers and payloads, inspect claims, and check the declared expiration window in your browser.

Decode a JSON Web Token

Read a three-part JWT, inspect common claims, and check its declared expiration window locally.

Signature not verified

Decoding a JWT does not verify its signature.

A decoded token should not be trusted unless its signature and claims are verified by the application that issued or accepts it.

Your JWT is decoded locally in your browser and is not sent to a server. JWTs can contain sensitive claims, so avoid sharing tokens unnecessarily.

Workflow

How to use the JWT Decoder

  1. Paste a three-part JWT into the decoder input, or load the synthetic sample token.
  2. Select Decode JWT.
  3. Review the decoded header, payload, common claims, and expiration status.
  4. Use Check time again to compare the same claims with the latest browser time.
  5. Copy the header or payload JSON when it is safe and useful to do so.

Decoding reads token content only. It does not verify the signature or trust the claims.

Overview

What is a JWT?

JWT stands for JSON Web Token. It is a compact format used to carry claims for scenarios such as authentication, authorization, and information exchange between systems.

This JWT decoder reads common three-part, JWS-style tokens. It does not support decoding five-part encrypted JWE content.

Anatomy

JWT structure

A typical signed JWT contains three dot-separated segments:header.payload.signature. The header and payload are Base64URL-encoded JSON. The signature is binary signing output represented as Base64URL text.

Metadata

JWT Header

The header describes token metadata. Common properties include alg, which names a signing algorithm, and typ, which can identify the token as a JWT. Reading an algorithm name does not prove that the algorithm or signature was verified.

Claims

JWT Payload

The payload contains claims about a subject, issuer, audience, time, or application data. In an ordinary signed JWT it is encoded rather than encrypted, so anyone with the token can usually read it. Sensitive secrets should not be placed in an unencrypted payload.

Trust

JWT Signature

A signature allows an application to check whether token content was modified and whether it was signed by a trusted party. Verification requires the correct algorithm, trusted key material, and application policy. This tool displays the segment but does not verify it.

Reference

Common JWT claims

  • iss: the token issuer.
  • sub: the subject represented by the token.
  • aud: an intended audience, as a string or array.
  • exp: the expiration NumericDate.
  • nbf: the not-before NumericDate.
  • iat: the issued-at NumericDate.
  • jti: an identifier for the JWT.

Security

JWT decoding vs verification

Decoding reads Base64URL content and parses JSON. Verification cryptographically checks the signature and also requires trusted issuer, audience, time, and policy decisions. Decoding a JWT does not verify its signature, and this tool performs decoding only.

Time

JWT expiration and timestamps

The exp, nbf, and iat claims commonly use NumericDate: Unix seconds counted from 1970-01-01T00:00:00Z. This decoder preserves the raw number and displays its UTC ISO 8601 representation when the value is numeric.

Use the Unix Timestamp Converterto inspect a NumericDate in UTC and local time. Expiration text on this page describes the claim relative to the current browser time; it does not declare that the token itself is valid or invalid.

Expiry

How the JWT expiration checker works

The checker follows the time-claim definitions in RFC 7519. At the exact expboundary or later, the expiration claim has passed. Before nbf, the declared not-before boundary has not arrived. The comparison uses the current browser clock and applies no clock-skew allowance.

A result such as Inside the declared time window describes only the decodedexp and nbf numbers. It is not a security verdict. The signature, algorithm, issuer, audience, revocation state, permissions, and application rules remain unverified.

Limits

JWT time-claim edge cases

  • A missing exp claim means the token declares no expiration boundary.
  • NumericDate values are seconds since the Unix epoch; fractional seconds can be represented.
  • A string such as "1700000000" is not a valid NumericDate number.
  • An exp value at or before nbf creates an empty or inverted time window.
  • A future iat may indicate clock mismatch or unusual token data, but this decoder does not enforce issuer policy.

Encoding

JWT vs Base64

JWT segments use Base64URL, which substitutes URL-safe characters and often removes padding. Standard Base64 uses a different alphabet for two characters and may include padding. For ordinary Base64 data, use theBase64 Encoder / Decoder.

Workflows

Common JWT decoding use cases

  • Inspect the declared signing algorithm and token type in the header.
  • Read subject, issuer, audience, role, or application-specific payload claims.
  • Convert exp, iat, and nbf values into readable times.
  • Debug an authentication flow before performing verification in the target application.

Keep exploring

Encoding

Base64 Encoder / Decoder

Encode UTF-8 text to Base64 or decode Base64 back to readable text directly in your browser.

View tool
JSON & Data

JSON Formatter

Format, beautify, validate and minify JSON directly in your browser.

View tool
Development

Unix Timestamp Converter

Convert Unix seconds, milliseconds, local dates, and ISO 8601 values directly in your browser.

View tool
JSON & Data

JSON Validator

Validate JSON syntax, locate parser errors, and inspect document structure directly in your browser.

View tool

Learn more

Published guide

How to Decode a JWT

Learn how to read JWT headers, payloads, Base64URL segments, and time claims while understanding why decoding is not verification.

Read guide

FAQ

Frequently asked questions

What is a JWT?

A JSON Web Token is a compact format for carrying claims between systems. Three-part signed JWTs commonly contain a Base64URL-encoded header, payload, and a signature segment.

Can anyone decode a JWT?

Anyone who obtains a typical signed JWT can usually decode its header and payload because Base64URL is encoding, not encryption. Decoding does not require the signing key.

Does decoding verify a JWT signature?

No. Decoding only reads the token segments. Signature verification requires the correct algorithm and trusted key plus application checks for issuer, audience, time claims, and policy.

Is a JWT payload encrypted?

A normal three-part signed JWT payload is not encrypted. Do not place secrets in it unless another appropriate encryption layer protects the information.

What do exp, iat and nbf mean?

exp is the expiration time, iat is the issued-at time, and nbf is the not-before time. They are commonly NumericDate values expressed as Unix seconds.

Can this JWT expiration checker prove that a token is valid?

No. It compares declared NumericDate claims with the browser clock. It does not verify the signature, issuer, audience, revocation state, permissions, or application policy.

What happens when a JWT has no exp claim?

The checker reports that no expiration claim is present. Because exp is optional in the general JWT format, its absence is not a parsing error, but it also does not make the token trustworthy or acceptable to an application.

Does the expiration check allow for clock skew?

No. This page compares claims directly with the current browser time and applies no leeway. Real applications may allow a small configured clock-skew tolerance.

Does this tool upload my JWT?

No. This tool decodes JWT content locally in your browser and does not send the token to a server.

What is the difference between Base64 and Base64URL?

Base64URL replaces + and / with URL-safe - and _, and JWT segments commonly omit = padding. This decoder restores those differences before decoding UTF-8 content.