JWT Decoder

Enter JWT & Secret

JWT Token

Secret (optional)

Header

Header will appear here

Payload

Payload will appear here

Signature

Signature will appear here

🔐 Understanding the JWT Structure

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. It is divided into three parts: Header, Payload, and Signature. Each part is Base64URL encoded and combined using dots.

Structure: `HEADER.PAYLOAD.SIGNATURE`
Part	Definition	Example	Purpose / Scenario
Header	Contains metadata about the token — including the algorithm and type of token.	{"alg":"HS256","typ":"JWT"}	Defines how the token is signed and verified (e.g., `HS256`,`RS256`).
Payload	Contains claims — data about the user or system. Claims can be registered (standard), public, or private.	{"sub":"1234567890","name":"John Doe","admin":true,"iat":1516239022}	Stores user identity and permissions. Used for access control, identity sharing, or session tracking.
Signature	Generated by signing the encoded header and payload using a secret key (HMAC) or a private key (RSA/ECDSA).	HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)	Verifies that the token hasn’t been tampered with and ensures authenticity of the sender.
Secret Key	A confidential key used to sign or verify the JWT. It must remain private on the server.	Example: `my_super_secure_256bit_secret_key`	Used in HMAC algorithms (e.g., HS256) to ensure only the issuer can generate valid tokens. Never expose this in frontend code or client apps.

🔸 Encoding: Each section (Header, Payload, Signature) is Base64URL encoded for URL-safe transmission.

🔸 Verification: The server decodes the token, recomputes the signature using the same secret/private key, and compares it with the received signature. If they match — the token is valid.

🔸 Common Algorithms: HS256 (HMAC + SHA256),RS256 (RSA), ES256 (ECDSA).

🔸 Best Practices: Use strong random secrets (≥256 bits), short token lifetimes (exp), and store secrets securely (e.g., environment variables or key vaults).

Limited Offer

Head first System Design

Limited Offer

Cracking PM Interview

Limited Offer

Designing Data-Intensive Applications

Limited Offer

Cracking the coding interview

Limited Offer

System Design Interview

Limited Offer

Patterns of Distributed Systems

🔍 Free Online JWT Decoder

Instantly **decode**, inspect and understand JSON Web Tokens (JWTs) — your go-to browser tool for token debugging, claim inspection, authentication flows and security audits. Fully client-side: **no data leaves your device**.

💡 What is a JSON Web Token (JWT)?

A JWT (JSON Web Token) is an open standard (RFC 7519) that defines a compact, URL-safe, self-contained way to represent claims to be transferred between two parties. Once issued, the token proves the identity and authorization of the bearer in a stateless way.

Think of a JWT like a “ticket” you carry: anyone can inspect the ticket (peek inside), but only the issuer can truly validate it.

🧩 JWT Structure — Header · Payload · Signature

Every JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature.

🔐 Header

This JSON object defines **metadata**: the token algorithm (e.g., HS256, RS256) and the token type (usually “JWT”).

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

📦 Payload (Claims)

Contains the **claims** — statements about an entity (typically the user) and any metadata. Claims can be:

Registered claims (e.g., iss, sub, exp, aud).
Public claims — custom fields defined in the application namespace.
Private claims — agreed upon by issuer and consumer.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

✍️ Signature

The signature ensures the token’s integrity — verifying that the header and payload weren’t tampered with and that the token was issued by a trusted credential.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

🔄 JWT Lifecycle & Usage Flow

Here’s a typical end-to-end flow for a JWT in an authentication/authorization context:

User logs in via client (browser, mobile app) with credentials (username/password).
Server verifies credentials, **issues a JWT** with claims including iss, sub, exp.
Client stores the JWT (e.g., HTTP-Only cookie or secure storage) and sends it with each protected request (commonly via Authorization: Bearer <token>).
Server receives request, validates token signature, verifies claims (exp, aud, iss) and then grants access to the requested resources.
Token expires or is revoked — optionally a refresh token is used for issuing a new JWT. Maintaining statelessness and session-scale across microservices.

🕵️‍♂️ Why Use a JWT Decoder?

A JWT decoder tool lets you instantly inspect the header and payload of tokens — decode Base64URL, parse claims, and spot issues like expired tokens or unexpected roles. Great for:

Debugging authentication flows and API access failures.
Validating token contents (role, scopes, expiration) during development.
Learning and teaching how JWTs are structured internally.
Performing security audits on tokens to check for misconfiguration.

⚙️ Common JWT Signing Algorithms

Algorithm	Type	Description
HS256	Symmetric	Same secret key for signing & verification. Simpler but less scalable in microservices.
RS256	Asymmetric	Private key signs, public key verifies — better for distributed systems.
ES256	Asymmetric (Elliptic Curve)	Smaller keys, faster verification, increasingly recommended.

Note: Choosing the correct algorithm is a key security decision — mismatched or “none” algorithm attacks are common.

🔒 Security Best Practices & Common Pitfalls

Using JWTs safely requires more than just issuing tokens — you must design and implement them securely. Here are essential practices:

Always transmit tokens over HTTPS to avoid interception.
Don’t store sensitive data in the payload — it’s only Base64-encoded, not encrypted.
Set a reasonable expiration time (exp) and enforce short-lived access tokens with refresh cycles.
Validate the signature, issuer (iss), audience (aud), expiration (exp), and any custom claims.
Use HTTP-Only, Secure cookies (with SameSite) or equivalent secure storage; avoid plain localStorage for sensitive tokens.
Be aware of algorithm‐confusion vulnerabilities — e.g., accepting “alg: none” or switching from RS256 to HS256.
Consider token revocation or blacklisting strategies if tokens live long or you need instant revocation.

❓ Frequently Asked Questions (FAQs)

How does this Decoder tool work?

It Base64URL-decodes the header and payload segments of your JWT and displays the JSON in a human-readable format. This client-side tool does *not* verify the signature; verification requires a secret or public key on the server.

Can I verify the JWT’s signature with this tool?

No — signature verification requires the appropriate secret or public key which is not safe to expose in the browser. For full verification, use your backend or CLI tool.

What if the JWT is expired?

The token can still be decoded, but once the exp (expiration) claim passes its timestamp, the token is no longer valid for resource access.

Should I always use JWTs instead of sessions?

Not necessarily — sessions still have valid use-cases (e.g., simple logic, immediate revocation). JWTs excel in stateless, distributed, micro-service environments, but come with complexity and potential pitfalls.

Encode a JWT