JWT Token Decoder

Paste any JSON Web Token to instantly decode the header, payload, and claims. Inspect expiry, token status, and registered claim descriptions — no secret key required.

Tokens are decoded on the server — no secret keys are ever sent or processed. The payload is Base64URL-encoded, not encrypted.

Decoding token...

Paste a JWT above and click Decode Token to inspect its contents.

What Is a JSON Web Token?

A JSON Web Token (JWT, pronounced "jot") is an open standard (RFC 7519) for securely transmitting claims between two parties as a compact, URL-safe JSON object. Unlike opaque session tokens, a JWT carries its own data — the server can validate it without a database lookup, making it ideal for stateless, distributed authentication.

Every JWT has three Base64URL-encoded segments separated by dots:

Header . Payload . Signature

The header names the algorithm. The payload contains the claims (data). The signature proves the header and payload have not been altered. The payload is encoded, not encrypted — anyone who holds the token can read the claims; only the signature prevents tampering.

Header Algorithms

The alg field in the header tells the verifier which algorithm was used to produce the signature.

alg	Family	Key type	Notes
HS256	HMAC-SHA256	Symmetric	Fast; both sides share the same secret key
HS384	HMAC-SHA384	Symmetric	Larger 384-bit digest variant
HS512	HMAC-SHA512	Symmetric	Largest HMAC digest; highest computational cost
RS256	RSA-SHA256 (PKCS1v15)	Asymmetric	Sign with private key, verify with public key — common OAuth 2.0 choice
RS384	RSA-SHA384	Asymmetric	Higher security RSA variant
RS512	RSA-SHA512	Asymmetric	Largest RSA digest
ES256	ECDSA P-256 + SHA256	Asymmetric	Smaller keys than RSA; preferred for modern APIs
ES384	ECDSA P-384 + SHA384	Asymmetric	Higher security ECDSA variant
ES512	ECDSA P-521 + SHA512	Asymmetric	Highest ECDSA security level
PS256	RSA-PSS + SHA256	Asymmetric	Probabilistic padding; FIPS 186-4 approved
none	None	—	⚠ Unsigned — no signature; never accept in production

Registered Payload Claims (RFC 7519)

RFC 7519 defines seven reserved claim names with well-known meanings. Using these consistently allows JWT libraries and services to interoperate without custom configuration.

Claim	Key	Type	Description
Issuer	iss	string	The entity that created and signed the token (e.g., https://auth.example.com)
Subject	sub	string	The principal the token describes — usually a user ID or service account
Audience	aud	string \| array	The service(s) the token is intended for; recipients must verify this value
Expiration	exp	integer	Unix timestamp (seconds) after which the token must be rejected
Not Before	nbf	integer	Unix timestamp before which the token must not be accepted
Issued At	iat	integer	Unix timestamp when the token was created — useful for calculating token age
JWT ID	jti	string	A unique token identifier; used to build a token denylist or prevent replay attacks

How the Signature Works

The signature binds the header and payload together. For an HS256 token, the server computes:

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

For RS256 and ES256, the private key signs the concatenated header and payload; the public key can verify the signature without knowing the private key. This is the asymmetric model used by most public identity providers (Google, Auth0, AWS Cognito).

Important: changing even one character in the header or payload produces a completely different signature, making the token invalid. The payload is not protected from reading — only from modification.

JWT vs Session Tokens

Both mechanisms achieve authentication; the right choice depends on your infrastructure and revocation requirements.

Aspect	JWT	Session Token
Storage	Client-side (cookie or localStorage)	Server-side (Redis, database)
Server lookup	None — payload decoded from the token itself	Required — session ID looked up in store
Revocation	Hard — needs denylist or very short TTL	Easy — delete the session from the store
Token size	200–800 bytes typically	Small opaque string (~32 bytes)
Scalability	Stateless; works across all servers without shared state	Requires a shared session store across servers
Secret rotation	Invalidates all existing tokens immediately	No impact on active sessions

Common Security Pitfalls

alg:none Attack

An attacker strips the signature and sets alg to "none". A misconfigured library that accepts the none algorithm will validate any payload without checking a signature. Always explicitly allowlist the algorithms your server accepts — never trust the alg value blindly.

Algorithm Confusion (RS256 → HS256)

Some libraries that verify RS256 tokens can be tricked into accepting an HS256 token signed with the public key as the HMAC secret. Because the public key is public, an attacker can forge tokens. Always lock the expected algorithm server-side — do not let the token header choose it.

Sensitive Data in Payload

The payload is Base64URL-encoded, not encrypted. Anyone who obtains the token can decode it immediately — no key required. Never store passwords, credit card numbers, PII, or other secrets in JWT claims. Use encrypted JWTs (JWE) if the payload must be confidential.

Frequently Asked Questions

Can I decode any JWT without the secret key?

Yes. The header and payload are simply Base64URL-encoded JSON — anyone can decode them using any Base64 decoder. The secret key (or private key) is only needed to verify the signature, not to read the payload. This is why you must never put sensitive information in a JWT payload unless you use JWE (JSON Web Encryption).

What is the difference between JWT expiry and session expiry?

JWT expiry (the exp claim) is baked into the token itself and enforced by the verifier. Once a JWT is signed, its expiry cannot be changed without issuing a new token. Session expiry is controlled entirely server-side — a session can be extended, shortened, or invalidated at any time by updating the session store, regardless of when the original session was created.

Is it safe to store JWTs in localStorage?

localStorage is accessible to any JavaScript running on the page, making it vulnerable to XSS attacks. If an attacker injects a script, they can steal all stored tokens. The safer alternative is an httpOnly, Secure, SameSite=Strict cookie, which is inaccessible to JavaScript. For high-security applications, combine short-lived access tokens with a server-side refresh token rotation strategy.

What does "Bearer" mean in the Authorization header?

Bearer is a token type defined in RFC 6750. The Authorization: Bearer <token> header tells the server that the request is authenticated by the possession of the token itself — whoever bears the token is granted access. No additional proof of identity (such as a client certificate) is required, which is why keeping JWTs confidential and short-lived is critical.

How do I refresh a JWT without re-logging in?

The standard approach is a refresh token flow. When the short-lived access token (JWT) expires, the client sends a long-lived, opaque refresh token to a dedicated /refresh endpoint. The server validates the refresh token (often from a secure store), issues a new access JWT, and optionally rotates the refresh token. Refresh tokens should be stored in httpOnly cookies and rotated on each use to detect theft.

What is the maximum size of a JWT?

There is no hard limit defined in the JWT specification (RFC 7519), but practical limits apply. HTTP headers have a typical limit of 4–8 KB depending on the server. Cookies have a 4 KB limit per domain. A typical HS256 JWT with a few claims is 200–500 bytes. RS256 tokens are larger due to the RSA signature (~342 bytes of Base64 alone). Keep payloads small — store only what is needed for authorization decisions, not full user profiles.