JWT Decoder

Decode and inspect JSON Web Tokens. View header, payload, and expiration status. 100% client-side.

Free to use. Runs in your browser.

Paste a JSON Web Token to decode its header, payload, and signature. All decoding happens locally in your browser, the token is never transmitted.

Paste a token to read its header and payload locally; decoding shows what is inside but does not verify the signature.

Paste JWT Token

Methodology and sources

Formula or method

Splits the token on its two dots into header, payload, and signature, then Base64URL-decodes the header and payload (which are plain JSON) and reads standard claims such as exp and iat. It does not recompute or check the signature.

Basis and assumptions

Decoding only: the 'Valid' status reflects the exp (expiry) claim, not authenticity. A decoded token is not a verified token.
A JWT payload is Base64URL-encoded, not encrypted, so anyone can read it. The signature makes it tamper-evident only when a server checks it with the signing key.
Everything runs in your browser; the token is not uploaded.

What this tool does not decide

Whether a token is authentic or untampered. Verify the signature server-side with the correct secret (HS*) or public key (RS*/ES*) before trusting any claim.
Authorisation. Never grant access based on a decoded payload alone.
Whether a token is safe to share. Treat JWT payloads as readable, and never paste production or secret-bearing tokens into online tools you do not control.

Sources

RFC 7519: JSON Web Token (JWT) (IETF) last accessed 2026-06-06
RFC 7515: JSON Web Signature (JWS) (IETF) last accessed 2026-06-06

Last checked: 2026-06-06

What Is a JWT and Why Should You Care?

A JSON Web Token (JWT) is a compact, URL-safe way of representing claims between two parties. In plain English: it's how most modern web apps handle authentication. When you log in, the server creates a JWT containing your identity and permissions, signs it cryptographically, and hands it back. Every subsequent request includes that token to prove who you are.

A JWT has three parts separated by dots: header.payload.signature. The header tells you the algorithm used. The payload contains the actual claims (user ID, roles, expiration). The signature ensures nobody has tampered with the first two parts.

This decoder splits the token and shows you the header and payload in readable JSON. It runs entirely in your browser, your tokens never leave your device. Perfect for debugging auth issues during development.

JWT Structure Explained

Part	Encoding	Contains	Example Fields
Header	Base64URL	Token metadata	alg (algorithm), typ (type)
Payload	Base64URL	Claims (data)	sub (subject), exp (expiry), iat (issued at)
Signature	Binary	Verification hash	HMAC-SHA256 or RSA-SHA256 output

What this means for you: The header and payload are just Base64URL-encoded JSON, anyone can read them. The signature is the only part that provides security. Never put sensitive data (passwords, credit card numbers) in a JWT payload.

Standard JWT Claims

Claim	Full Name	Purpose
iss	Issuer	Who created the token (e.g., auth.myapp.com)
sub	Subject	Who the token identifies (usually user ID)
aud	Audience	Who should accept this token (e.g., api.myapp.com)
exp	Expiration	Unix timestamp when the token expires
iat	Issued At	Unix timestamp when the token was created
nbf	Not Before	Token is invalid before this time
jti	JWT ID	Unique identifier to prevent replay attacks

Common JWT Debugging Tips

Token expired?

Check the "exp" claim. It's a Unix timestamp, convert it to a human-readable date to see when it expired. If your app gets 401 errors after a while, the token lifetime is likely too short.

Wrong permissions?

Look for "roles", "scope", or custom claims in the payload. If a user can't access a resource, their token might be missing the required role or scope claim.

Signature invalid?

The server's signing key might have rotated, or the token was modified in transit. This decoder doesn't verify signatures, it just reads the payload. Use server-side verification for security.

Never store JWTs in localStorage

localStorage is vulnerable to XSS attacks. Use HttpOnly cookies for auth tokens in production. Session storage is slightly better but still accessible to scripts on the same page.

JWT vs Session Cookies

Feature	JWT (Stateless)	Session Cookie (Stateful)
Server storage	None, token is self-contained	Session store (Redis, DB)
Scalability	Easy, any server can verify	Needs shared session store
Revocation	Hard, token valid until expiry	Easy, delete from store
Size	~800 bytes typical	~32 byte session ID
Best for	APIs, microservices, mobile	Traditional web apps, SPAs

What this means for you: JWTs shine in distributed systems where multiple services need to verify identity without sharing a database. Session cookies are simpler and more secure for single-server web apps because you can revoke them instantly.

Signing Algorithms at a Glance

The header's alg field names how the signature was produced. This decoder shows you which one a token claims to use, but the algorithm only matters at verification time, on the server, never in the browser.

alg	Family	Key	Typical use
HS256 / HS384 / HS512	HMAC + SHA-2	One shared secret	Internal services that share a key
RS256 / RS384 / RS512	RSA + SHA-2	Private signs, public verifies	Distributed systems, public verification
ES256 / ES384 / ES512	ECDSA	EC private / public pair	Like RSA with smaller, faster keys
PS256 / PS384 / PS512	RSA-PSS	Private / public pair	Modern RSA padding, where supported
none	No signature	None	Must be rejected by verifiers (see below)

What this means for you: a symmetric algorithm (HS*) verifies with the same secret it was signed with, so that secret must stay on the server. An asymmetric algorithm (RS*, ES*, PS*) lets anyone verify with the public key while only the issuer can sign.

Decoded Is Not Verified: the One Rule That Matters

This tool, like every browser-based decoder, reads the header and payload but does not check the signature. "Decoded" tells you what a token claims; only verifying the signature on the server tells you whether to believe it. Two classic attacks exist precisely because some systems skipped that step:

The alg: none attack. An attacker sets the header algorithm to none and strips the signature. A verifier that trusts the header will accept a forged token, so verifiers must reject none and pin the algorithm they expect.
RS256 to HS256 key confusion. An attacker switches an RSA token to HMAC and signs it with the public key, which is by definition public. A verifier that does not pin the algorithm may accept it. Always fix the algorithm server-side rather than reading it from the token.

Server-side verification checklist

Verify the signature with the correct key before reading any claim.
Pin the expected algorithm; never trust the header's alg blindly, and reject none.
Check exp and nbf for the valid time window, and validate iss and aud against what you expect.
Keep token lifetimes short and pair them with refresh tokens; keep a revocation or token-version check where you need instant logout.
Store tokens in HttpOnly, Secure, SameSite cookies rather than localStorage, and never place passwords or secrets in the payload.

Related Tools

Base64 Encoder/Decoder

Encode and decode Base64 strings

JSON Formatter

Format JWT payload JSON

Hash Generator

Generate SHA-256 and other hashes

Unix Timestamp Converter

Convert JWT exp/iat timestamps

URL Encoder/Decoder

Encode tokens for URL transport

Password Generator

Generate secure JWT signing secrets

How to use this tool

Paste your JWT token into the input field

Click Decode to view the header and payload

Check the expiration status and claim values

Common uses

Debugging authentication issues in web apps
Inspecting token claims and permissions
Checking token expiration during development
Verifying JWT structure before API calls
Understanding OAuth2 and OIDC token contents

Share this tool

Frequently Asked Questions

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format used for authentication. It has three parts separated by dots: header.payload.signature. The header specifies the algorithm, the payload contains claims (user data), and the signature prevents tampering.

Can this tool verify JWT signatures?

No, this decoder reads the header and payload (which are just Base64URL-encoded JSON that anyone can read). Signature verification requires the server's secret key or public key. This tool is for inspecting tokens, not validating them.

Is it safe to paste my JWT here?

Yes. Everything runs in your browser, your token never leaves your device. No data is sent to any server. That said, JWTs contain user data (IDs, roles, emails), so don't paste production tokens in tools you don't trust.

Why does my JWT say 'expired'?

The 'exp' (expiration) claim is a Unix timestamp. If the current time is past that timestamp, the token is expired. Check the decoded payload for the exp value. Short-lived tokens (15 minutes to 1 hour) are a security best practice.

What's the difference between HS256 and RS256?

HS256 (HMAC-SHA256) uses a shared secret, both the issuer and verifier know the same key. RS256 (RSA-SHA256) uses a public/private key pair, only the issuer has the private key, anyone can verify with the public key. RS256 is preferred for distributed systems.

What are standard JWT claims?

iss (issuer), sub (subject/user ID), aud (audience), exp (expiration), iat (issued at), nbf (not before), jti (unique ID). These are optional but widely used. Custom claims (roles, permissions, email) can be added alongside them.

Should I store JWTs in localStorage or cookies?

Cookies with HttpOnly, Secure, and SameSite flags are more secure, they're not accessible to JavaScript, which protects against XSS attacks. localStorage is vulnerable to XSS. Session storage is slightly better but still script-accessible.

How do I decode a JWT in JavaScript?

Split on dots, Base64URL-decode the first two parts: token.split('.').slice(0,2).map(p => JSON.parse(atob(p.replace(/-/g,'+').replace(/_/g,'/')))). The first element is the header, the second is the payload.

Can JWTs be revoked?

Not directly, JWTs are stateless. Once issued, they're valid until expiration. To 'revoke' them, use short expiration times with refresh tokens, maintain a server-side blocklist, or use token versioning where the server rejects old versions.

Why shouldn't I put sensitive data in a JWT?

The payload is just Base64URL-encoded, anyone can decode it without the signing key. Never put passwords, credit card numbers, or private data in a JWT. Treat the payload as public information that happens to be tamper-proof.

What causes 'invalid JWT format' errors?

A valid JWT has exactly three parts separated by dots (header.payload.signature). Common issues: extra whitespace, missing parts, corrupted Base64 encoding, or pasting only part of the token. Make sure you copy the complete token string.

What's the difference between JWT and session cookies?

Session cookies store a session ID, the server looks up user data. JWTs contain the user data itself, no server lookup needed. JWTs scale better (no session store) but are harder to revoke. Most apps use a combination: JWT for API auth, cookies for web sessions.

Results are for general informational purposes only and should be checked before use. They are not professional advice. See our Disclaimer and Terms of Service.