Free JWT Decoder — Decode, Verify & Build JSON Web Tokens

Decode any JWT instantly — see header, payload, and all claims with explanations. Verify HS256/RS256/ES256 signatures using the Web Crypto API. Build and sign new tokens. Every claim is explained. No server, no account — 100% browser-based.

Paste JWT

Header

Payload

Signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMzQ1IiwibmFtZSI6IkpvaG4gRG9lIiwiZW1haWwiOiJqb2huQGV4YW1wbGUuY29tIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzM4MDAwMDAwLCJleHAiOjE3Njk1MzYwMDB9.placeholder_signature_for_demo

Header

Algorithm: HS256

HMAC + SHA-256 — symmetric, shared secret

Type: JWT

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

Payload — Claims

6 claims

subSubject

Who the token refers to — typically a user ID

user_12345

nameName

Full name of the authenticated user

John Doe

emailEmail

User's email address

john@example.com

roleRole

Single role assigned to the user

admin

iatIssued At

Unix timestamp recording when the token was created

1738000000

expExpiration

Unix timestamp — token must be rejected after this time

1769536000

Signature

The signature prevents tampering. It is computed as HS256(base64url(header) + "." + base64url(payload), secret). Decoding a JWT does not require the secret — anyone can read the payload. Only verification requires the key.

placeholder_signature_for_demo

HMAC (HS256/384/512) · symmetricRSA (RS256/384/512) · asymmetricECDSA (ES256/384/512) · asymmetricRSA-PSS (PS256/384/512) · asymmetric

🔍

Decode Any JWT Instantly

Paste any JWT and instantly see the decoded header, payload, and signature. Every claim is explained — iss, sub, aud, exp, iat, nbf, jti, and all standard OIDC claims.

⏱️

Expiry & Timing Analysis

Timestamp claims (exp, nbf, iat) display as human-readable dates with VALID / EXPIRED / NOT YET badges and relative times like '2h 14m ago'. Expired tokens are flagged immediately.

🛡️

Signature Verification

Verify HS256/HS384/HS512 with a secret, and RS256/RS384/RS512/ES256/ES384/ES512/PS256+ with a PEM public key — using the Web Crypto API directly in your browser. No server involved.

🔑

JWT Builder

Build and sign a JWT from scratch — add custom claims, use quick-add buttons for iss/sub/exp/iat/jti, select HS256/384/512, enter your secret, and generate a signed token instantly.

⚠️

Security Warning System

Automatically flags dangerous patterns: alg:none tokens, expired tokens, nbf violations, missing algorithm claims, and known insecure configurations — before you copy or use the token.

🔒

100% Private

All decoding, verification, and signing happens in your browser using the Web Crypto API. No JWT is ever sent to any server. Works offline. No account, no tracking.

Related Tools

{}

JSON Formatter

Format, validate, and auto-repair JSON with live preview, syntax error detection, sort keys A-Z, and one-click copy or download

{}↓

JSON Minifier

Compress JSON by removing all whitespace. Shows original size, minified size, bytes saved, and percentage reduction.

⇄

JSON to CSV Converter

Convert JSON arrays to CSV and CSV back to JSON. Nested object flattening, multi-delimiter support, type detection.

⇄

JSON to YAML Converter

Convert JSON to YAML for Kubernetes, Docker Compose, and config files. Also converts YAML back to JSON.

⟺

JSON Diff Tool

Compare two JSON objects side-by-side. Color-coded diff showing added, removed, changed, and unchanged keys with dot-notation paths.

🌲

JSON Tree Viewer

Visualize JSON as an interactive collapsible tree with color-coded types, live search, and node statistics.

⇄

JSON to XML Converter

Convert JSON to well-formed XML with configurable root element. Also converts XML back to JSON using browser DOMParser.

⇒

JSON to SQL Converter

Convert JSON arrays to MySQL, PostgreSQL, or SQLite INSERT statements with auto type detection, CREATE TABLE, and batch insert support.

⏰

Cron Expression Generator & Explainer

Build cron expressions visually, explain any expression in plain English, preview next 10 run times, and convert to AWS EventBridge, Spring/Quartz, Kubernetes, and GitHub Actions formats.

✓→

TODO Formatter

Format and organize TODO comments for better readability.

⬛

QR Code Generator

Generate QR codes for URL, WiFi, vCard, UPI payment, WhatsApp, email, SMS, and 5 more types with color customization and logo overlay

🔗

Slug Generator

Generate SEO-friendly URL slugs in 8 formats — kebab, snake, camelCase, PascalCase, and more

What Is a JWT? Structure and How It Works

A JSON Web Token is a compact, self-contained string used to securely transmit information between parties. Every JWT is made of three parts, separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJKb2huIERvZSIsImV4cCI6MTc2OTUzNjAwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Part	Color	What it Contains	Requires Key?
Header	Rose/Red	Algorithm (alg), token type (typ), optional key ID (kid)	No — anyone can decode
Payload	Violet	Claims: user ID, roles, expiry, any custom fields	No — anyone can decode
Signature	Blue	HMAC or RSA/ECDSA signature of header + payload	Yes — needed to verify

Common misconception: JWTs are NOT encrypted. The payload is just base64url-encoded — any person or tool can read it without a key. Never store passwords, credit card numbers, or secrets in a JWT payload.

Standard JWT Claims — Complete Reference

RFC 7519 defines seven registered claims. OpenID Connect (OIDC) adds additional standard claims for identity tokens. All other claims are application-specific.

Claim	Full Name	Type	Description
iss	Issuer	String	URI of the application that issued the token
sub	Subject	String	Unique identifier of the user or entity the token refers to
aud	Audience	String/Array	Service(s) that should accept this token. Must be validated.
exp	Expiration Time	Number	Unix timestamp. Token must be rejected after this time.
nbf	Not Before	Number	Unix timestamp. Token must be rejected before this time.
iat	Issued At	Number	Unix timestamp of when the token was created.
jti	JWT ID	String	Unique ID for this token. Used to prevent replay attacks.
name	Full Name	String	Full display name of the authenticated user (OIDC).
email	Email	String	Email address of the user (OIDC).
email_verified	Email Verified	Boolean	Whether the email has been confirmed (OIDC).
scope	Scope	String	Space-separated list of OAuth 2.0 scopes granted.
azp	Authorized Party	String	Client ID the token was issued to. Used in OIDC.

JWT Signing Algorithms — Which One Should You Use?

The algorithm is declared in the JWT header's alg field. Choosing the right one depends on your architecture:

Algorithm	Type	Key	Speed	Best For
HS256	HMAC	Shared secret (32+ bytes)	Very fast	Monolith, single-service apps, internal APIs
RS256	RSA	RSA key pair (2048+ bits)	Moderate	Microservices, third-party token consumers
ES256	ECDSA	EC key pair (P-256)	Fast	Mobile apps, IoT — smaller keys, same security as RS256
PS256	RSA-PSS	RSA key pair (2048+ bits)	Moderate	FIPS-compliant systems, highest-security requirements
none	None	None	—	NEVER USE — critical security vulnerability

Use HS256 when…

• You have a single backend that both issues and verifies tokens
• You can securely store and rotate a shared secret
• Simplicity and performance are priorities
• You do NOT share tokens with third-party services

Use RS256/ES256 when…

• Multiple services need to verify tokens independently
• You expose a JWKS endpoint for public key distribution
• Third-party applications consume your tokens
• You use an identity provider (Auth0, Cognito, Keycloak)

JWT Security Best Practices

Always validate the algorithm

Never let the client or the JWT header dictate which algorithm to use for verification. Hardcode the expected algorithm on the server side. This prevents algorithm confusion attacks (e.g. an attacker swapping RS256 for HS256 and using the public key as the HMAC secret).

Always validate exp, nbf, and aud

Expiry (exp) prevents tokens from being used indefinitely after a user logs out or changes their password. Not Before (nbf) prevents use before the intended time. Audience (aud) prevents a token issued for Service A from being replayed against Service B.

Keep tokens short-lived

Access tokens should expire in 15 minutes to 1 hour. Longer lifetimes mean a stolen token grants access for longer. Use refresh tokens (stored securely in HttpOnly cookies) to issue new access tokens without forcing re-login.

Never store sensitive data in the payload

JWT payloads are only base64url-encoded — anyone can decode them. Never include passwords, API keys, PII beyond what is necessary, or data that would be a problem if leaked. Store minimal data: user ID, roles, expiry.

Use strong, unique secrets

For HS256/384/512, use a secret of at least 32 bytes (256 bits) generated from a cryptographically secure random number generator. Never use predictable strings like 'secret', 'password', or your app name. Rotate secrets regularly and ensure they are not exposed in code repositories.

Implement token revocation for critical actions

JWTs cannot be instantly revoked before expiry. For high-security scenarios (password change, account deletion, privilege change), maintain a short-lived blocklist of revoked JWT IDs (jti claim) or rotate signing keys to invalidate all previously issued tokens.

Frequently Asked Questions

What is a JWT and how does it work?▼

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information as a JSON object. A JWT has three parts separated by dots: the header (which algorithm is used), the payload (the actual data — called claims), and the signature (which proves the token hasn't been tampered with). The header and payload are base64url-encoded, not encrypted, so anyone can read them. The signature is created using a secret key or private key and is the only part that requires a key to verify.

What are the three parts of a JWT?▼

A JWT looks like xxxxx.yyyyy.zzzzz. The first part (header) is a base64url-encoded JSON object specifying the algorithm (alg) and token type (typ). The second part (payload) is a base64url-encoded JSON object containing claims — pieces of information about the user or session such as sub (user ID), exp (expiration time), iat (issued at), and any custom claims. The third part (signature) is computed by signing the base64url(header).base64url(payload) string with the secret or private key. Without the secret, you can read the header and payload but cannot forge a valid signature.

Can I decode a JWT without the secret key?▼

Yes. Decoding only requires base64url-decoding the header and payload — no key is needed. This is because JWTs are not encrypted by default; they are only signed. This is a common misconception. The signature prevents tampering (you cannot modify the payload and produce a valid signature without the key), but it does not hide the data. Never store sensitive information like passwords or credit card numbers in a JWT payload. If you need to encrypt the contents, use JWE (JSON Web Encryption) instead.

What is the difference between HS256 and RS256?▼

HS256 uses HMAC with SHA-256 — a symmetric algorithm where both the signer and verifier share the same secret. It is fast and simple, but every service that needs to verify tokens must have a copy of the secret. RS256 uses RSA with SHA-256 — an asymmetric algorithm where the issuer signs with a private key and any service verifies with the public key. RS256 is preferred in microservice architectures because services only need the public key (which is safe to distribute) and never see the private key. ES256 (ECDSA) is similar to RS256 but uses shorter keys for the same security level.

Is a JWT encrypted?▼

No — a standard JWT (called JWS, JSON Web Signature) is NOT encrypted. The payload is only base64url-encoded, which anyone can decode instantly. Base64url is an encoding scheme, not encryption. If you paste any JWT into our decoder, you can read all the claims without any key. JWTs are designed to be verifiable (tamper-proof via signature) but not confidential. If you need to encrypt the payload, the standard is JWE (JSON Web Encryption), which produces a different structure with five parts instead of three.

What happens when a JWT expires?▼

The exp (expiration) claim contains a Unix timestamp. When the current time is past this timestamp, the token is considered expired and must be rejected by the server. Clients typically handle this by requesting a new access token using a refresh token. The server should always validate exp before trusting any other claim — never skip expiry validation. In our decoder, we automatically detect expired tokens and show a red EXPIRED badge on the exp claim, along with a warning at the top of the decoded view.

What is the alg:none vulnerability in JWT?▼

The 'alg:none' attack is a critical JWT vulnerability. Some libraries once allowed a token with alg set to 'none' to skip signature verification entirely. An attacker could take any valid JWT, change the payload (e.g. elevate their role to admin), set alg to 'none', remove the signature, and submit it — and vulnerable servers would accept it. All modern JWT libraries reject alg:none by default. Our tool flags any JWT with alg:none with a critical security warning. Never allow clients to specify the algorithm — always enforce a specific algorithm on the server side.

Where should I store JWTs — localStorage or cookies?▼

Both options have trade-offs. localStorage is vulnerable to XSS attacks — any injected script can read and exfiltrate the token. HttpOnly cookies are not accessible to JavaScript, making them immune to XSS, but they are vulnerable to CSRF attacks (mitigated by using SameSite=Strict or CSRF tokens). The recommended approach depends on your threat model: for most web applications, HttpOnly cookies with SameSite=Strict protection are considered safer because XSS is a more common attack vector than CSRF. For mobile apps or SPAs calling third-party APIs, secure token storage mechanisms provided by the platform should be used.

What is the maximum size of a JWT?▼

JWTs have no official size limit, but practical limits apply. Cookies have a 4 KB limit per domain. HTTP headers typically limit to 8 KB per header (configurable in servers). URL query strings may be limited to 2,048 characters in some browsers. A typical JWT with standard claims and an HS256 signature is 200–400 bytes. Large numbers of custom claims, long user IDs, or embedding large arrays (like permissions lists) can push a JWT to several kilobytes. Keep JWTs small — store only what is needed for authorization checks.

What is the difference between JWT and an opaque session token?▼

An opaque session token (like a random 32-byte string) has no meaningful content — the server must look it up in a database or cache on every request to find the associated session data. A JWT is self-contained — all the information (user ID, roles, expiration) is encoded in the token itself. The server can verify and read the claims without a database lookup, which is why JWTs are popular for stateless microservices. The downside is that JWTs cannot be instantly revoked before their expiry — to revoke a JWT, you need a token blocklist (which reintroduces state). For single-server applications, opaque session tokens stored server-side are often simpler and more controllable.

What are JWKS (JSON Web Key Sets)?▼

JWKS (JSON Web Key Set) is a standard format (RFC 7517) for publishing a set of public keys used to verify JWTs. Identity providers like Auth0, Google, and Okta expose a JWKS endpoint (e.g. /.well-known/jwks.json) containing their current public keys. When a service receives a JWT, it fetches the JWKS, finds the key matching the kid (key ID) in the JWT header, and uses that public key to verify the signature. This allows key rotation without updating every service — when the provider rotates keys, they publish the new key in the JWKS and services automatically pick it up.

What standard JWT claims should every token include?▼

At minimum, every JWT should include: iss (issuer — which application issued the token), sub (subject — the user ID), aud (audience — which service should accept the token), exp (expiration — when the token becomes invalid), and iat (issued at — when it was created). The aud claim is particularly important and often overlooked — without it, a token issued for one of your services can be replayed against another. Always validate iss, aud, exp, nbf, and the signature on every request. The jti (JWT ID) claim should be used when you need token replay prevention.

Free JWT Decoder — Decode, Verify & Build JSON Web Tokens

Header

Payload — Claims

Signature

Decode Any JWT Instantly

Expiry & Timing Analysis

Signature Verification

JWT Builder

Security Warning System

100% Private

Related Tools

JSON Formatter

JSON Minifier

JSON to CSV Converter

JSON to YAML Converter

JSON Diff Tool

JSON Tree Viewer

JSON to XML Converter

JSON to SQL Converter

Cron Expression Generator & Explainer

TODO Formatter

QR Code Generator

Slug Generator

What Is a JWT? Structure and How It Works

Standard JWT Claims — Complete Reference

JWT Signing Algorithms — Which One Should You Use?

Use HS256 when…

Use RS256/ES256 when…

JWT Security Best Practices

Always validate the algorithm

Always validate exp, nbf, and aud

Keep tokens short-lived

Never store sensitive data in the payload

Use strong, unique secrets

Implement token revocation for critical actions

Frequently Asked Questions

Popular Tools

Image Compress

Age Calculator

Fake Chat Generator

BMI Calculator

Percentage Calculator

JSON Formatter

Word Counter

QR Code Generator

Password Generator

SIP Calculator

Categories