Skip to main content
VClick Tools
DEVELOPER & WEB TOOLS100% Client-Side

JWT Decoder

Decode, inspect, and analyze JSON Web Tokens locally in your browser. View JOSE headers, payload claims, expiration timestamps, and signature segments with zero server uploads.

100% Client-SideNo Signup RequiredInstant Analysis
100% Client-Side Inspection: Tokens are decoded purely in your browser memory. No server uploads, no network telemetry, and no storage persistence.
Zero Logging

Decoding Does Not Prove Authenticity

JWT payloads are Base64URL-encoded, not encrypted. Anyone can inspect claims. Signature verification is not performed here, meaning decoded tokens may be forged.

Structure: Valid (3-Part)Signature: Not Verified
Expiration (exp)Not expired

Expires in In 1193 days (Jan 1, 2030, 12:00:00 AM)

UTC: Tue, 01 Jan 2030 00:00:00 GMT
Not Before (nbf)Not-before passed

Active since 1045 days ago (Nov 14, 2023, 10:13:20 PM)

UTC: Tue, 14 Nov 2023 22:13:20 GMT
Issued At (iat)Issued timestamp recorded

Issued 1045 days ago (Nov 14, 2023, 10:13:20 PM)

UTC: Tue, 14 Nov 2023 22:13:20 GMT
1. JOSE Header(HS256)
{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "v1-2026"
}
3. Signature (Base64URL)
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Signature verification not performed (Requires secret / public key).
2. Decoded Payload (Claims Set)(10 claims • 366 B)
{
  "iss": "https://api.vclick-tools.dev",
  "sub": "user_987654321",
  "aud": [
    "https://api.vclick-tools.dev",
    "v-dashboard"
  ],
  "exp": 1893456000,
  "nbf": 1700000000,
  "iat": 1700000000,
  "jti": "ca9f48d1-8dcf-4848-be45-7a90fbebec1a",
  "roles": [
    "admin",
    "developer"
  ],
  "profile": {
    "name": "VClick Security Analyst",
    "email": "developer@vclick-tools.com",
    "is_verified": true
  },
  "preferred_theme": "dark"
}

Claims Inspector (10)

3 Custom / 7 Registered
ClaimTypeDecoded ValueInterpretation / RFC Meaning
issRFC 7519stringhttps://api.vclick-tools.devIssuer — Identifies the principal that issued the JWT
subRFC 7519stringuser_987654321Subject — Identifies the principal that is the subject of the JWT
audRFC 7519array [2]["https://api.vclick-tools.dev","v-dashboard"]Audience — Identifies the recipients that the JWT is intended for
expRFC 7519number1893456000Expiration Time — Identifies the expiration time on or after which the JWT MUST NOT be accepted
nbfRFC 7519number1700000000Not Before — Identifies the time before which the JWT MUST NOT be accepted for processing
iatRFC 7519number1700000000Issued At — Identifies the time at which the JWT was issued
jtiRFC 7519stringca9f48d1-8dcf-4848-be45-7a90fbebec1aJWT ID — Case-sensitive unique identifier for the token (prevents replay)
rolesarray [2]["admin","developer"]Custom application claim
profileobject{"name":"VClick Security Analyst","email":"developer@vclick-tools.com","is_verified":true}Custom application claim
preferred_themestringdarkCustom application claim
Total Length591Characters
Header Segment58Chars (Base64)
Payload Segment488Chars (Base64)
Signature Segment43Chars (Base64)
AlgorithmHS256JOSE 'alg'
Claims Count103 Custom
STEP-BY-STEP GUIDE

How to Decode and Inspect a JWT Online

1

Paste Your JWT

Paste your compact token string or Bearer authorization header directly into the token input editor.

2

Automatic Segment Detection

The decoder strips Bearer prefixes, verifies the 3 dot-separated segments, and decodes Base64URL to JSON.

3

Inspect Header and Signature

View the JOSE header signing algorithm (alg) and key ID (kid), along with the raw signature segment.

4

Analyze Payload Claims

Review formatted payload JSON, claim data types, subject identifiers, and registered claim interpretations.

5

Check Expiration and Copy

Check relative expiration time and copy individual decoded header, payload, or signature blocks.

Definition & Role

What Is a JWT Decoder?

A JWT (JSON Web Token) decoder is a developer utility designed to inspect, parse, and unpack the contents of RFC 7519 tokens. It converts URL-safe Base64-encoded binary segments into readable JSON structures representing the cryptographic header and the claims payload.
Unlike backend token verifiers that validate cryptographic signatures using private or public keys, a decoder focuses on inspecting token structure and claims. It enables developers to debug authentication flows, check user scopes, and troubleshoot expiration issues directly in the browser.
Workflow

How to Decode a JWT

Decoding a JSON Web Token in VClick Tools requires simply pasting your token string into the input area. The tool automatically detects whether a 'Bearer ' prefix is present, trims surrounding whitespace, splits the token across period delimiters, and unpacks the JSON objects in real time.
All parsing occurs entirely inside client-side JavaScript memory. No network requests are dispatched, no authentication data is logged, and no tokens are stored in browser storage, ensuring complete developer privacy.
Architecture

Understanding the Three JWT Parts

A standard compact JWS/JWT is composed of three distinct segments separated by periods (.): header.payload.signature.
The first segment is the JOSE (JSON Object Signing and Encryption) Header, the second is the Claims Set Payload, and the third is the cryptographic signature generated by hashing the header and payload with a secret key or private certificate.
JOSE Header

JWT Header Explained

The JOSE Header specifies the cryptographic metadata necessary for validating and processing the token. Its primary properties include alg (the cryptographic signing algorithm, such as HS256 or RS256) and typ (the token type, typically 'JWT').
Optional header parameters include kid (Key ID, identifying which specific key or certificate was used to sign the token) and cty (Content Type, used in nested token structures).
Claims Set

JWT Payload and Claims

The payload represents the central data package of the JWT, known as the Claims Set. Claims are key-value pairs representing statements about an entity (typically the authenticated user) and additional operational metadata.
Claims are categorized into three classes: Registered Claims (standardized by IETF in RFC 7519), Public Claims (registered in the IANA JSON Web Token Claims Registry), and Private Claims (custom application-specific keys).
Cryptographic Integrity

JWT Signature Explained

The signature is calculated by taking the Base64URL-encoded header, concatenating it with a period and the Base64URL-encoded payload, and signing that combined string using the algorithm declared in the header.
The signature ensures that the token payload cannot be altered in transit without detection by the verifying backend. However, the signature itself does not hide the payload data from anyone who possesses the token.
Encoding Standard

Base64URL Encoding in JWTs

JWTs utilize Base64URL encoding (RFC 4648 §5) rather than standard Base64. Base64URL replaces standard characters + and / with URL-safe alternatives - and _, and omits trailing = padding characters.
This ensures that tokens can be safely transmitted in HTTP Authorization headers, query parameters, and cookie strings without being corrupted by URL encoding rules.
IETF Standards

JWT Registered Claims

RFC 7519 defines seven standard registered claims: iss (Issuer), sub (Subject), aud (Audience), exp (Expiration Time), nbf (Not Before), iat (Issued At), and jti (JWT ID).
While none of these claims are universally mandatory according to the specification, robust security architectures frequently require iss, sub, aud, and exp to prevent token misuse across different services.
Token Lifetime

Understanding the exp Claim

The exp claim identifies the expiration timestamp on or after which the JWT must not be accepted for processing. It is represented as a NumericDate (seconds elapsed since Unix epoch: 1970-01-01T00:00:00Z UTC).
Our decoder converts raw numeric timestamps into human-readable local and UTC times and computes relative time remaining, clearly highlighting expired tokens in red.
Time Constraints

Understanding nbf and iat

The nbf (Not Before) claim specifies the exact timestamp before which the token must not be accepted, allowing systems to issue tokens that only activate in the future.
The iat (Issued At) claim records the timestamp when the token was originally generated. Verifying applications use iat to calculate token age or revoke all tokens issued before a user changed their credentials.
Identity Context

Issuer, Subject, and Audience Claims

The iss claim identifies the authority that minted the token (such as an OAuth 2.0 / OIDC authorization server). The sub claim identifies the principal or user ID represented by the token.
The aud claim identifies the target systems or API endpoints that are authorized to accept the token. Audience can be a single string or an array of strings representing multiple resource servers.
Application Data

Custom JWT Claims

Custom claims allow applications to embed user profile attributes, enterprise tenant IDs, assigned RBAC roles, and feature flags directly into the token payload.
Our claims inspector table displays all custom claims alongside their JSON types (string, number, boolean, array, or object), providing a transparent view of identity and permissions data.
Lifecycle States

JWT Expiration and Token Status

A token can exist in multiple lifecycle states based on its timestamps: Active (valid time window), Expired (past its exp boundary), or Inactive (prior to its nbf activation).
Our inspector evaluates these states dynamically against your computer's clock, categorizing tokens without making false assumptions about cryptographic validity.
Security Distinctions

JWT Decoding vs Signature Verification

There is a fundamental difference between decoding a token and verifying it. Decoding simply reads the Base64URL text; it does NOT verify that the signature was generated with a legitimate secret key.
An attacker can easily forge a JWT payload and recalculate or omit the signature. Backend applications must always cryptographically verify the signature before granting access to protected resources.
Data Protection

JWT Security and Sensitive Data

Because standard JWT payloads are merely Base64URL-encoded and not encrypted, anyone with access to the token (via network logs, browser storage, or client scripts) can read its entire contents.
Never store sensitive information such as plaintext passwords, credit card numbers, private encryption keys, or proprietary API secrets inside JWT claims.
HTTP Authorization

JWT and Bearer Authorization Tokens

In modern REST and GraphQL APIs, JWTs are typically transmitted in the HTTP Authorization request header using the Bearer scheme (Authorization: Bearer <token>).
Our decoder automatically detects when a copied header includes the Bearer prefix and cleans it before parsing, saving developers the manual step of trimming prefixes.
Developer Privacy

Privacy and Browser-Based JWT Decoding

Pasting real authentication tokens into online decoders carries inherent security risks if those tools log inputs to external analytics or backend servers.
VClick Tools guarantees 100% browser-local execution. All parsing occurs in ephemeral JavaScript memory with zero telemetry, zero logging, and zero external network requests.
Engineering Standards

JWT Debugging Best Practices

When troubleshooting API authentication issues, inspect the exp timestamp for clock skew, ensure the aud claim matches your API identifier, and verify that the alg matches your backend verifier configuration.
Always use short-lived access tokens (5 to 15 minutes) paired with secure refresh tokens to minimize the blast radius if an access token is intercepted.
FAQ

Frequently Asked Questions

Common questions about JWT Decoder and how it works.

Was this tool useful?

Your feedback helps us improve VClick Tools.