JWT Decoder Guide: How to Read and Validate JSON Web Tokens

What Is a JSON Web Token?

A JSON Web Token (JWT, pronounced “jot”) is a compact, URL-safe token format defined in RFC 7519. It lets two parties exchange claims — small pieces of JSON data — in a way that can be verified and trusted.

JWTs are everywhere. Auth0 reports that their platform alone processes over 4.5 billion logins per monthusing JWTs. If you've logged into a web app today, there's a good chance a JWT was involved.

JWT Structure: The Three Parts

Every JWT consists of three Base64URL-encoded sections separated by dots:

xxxxx.yyyyy.zzzzz

1. Header

The header typically contains two fields: the signing algorithm (alg) and the token type (typ). For example:

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

2. Payload (Claims)

The payload carries the claims — the actual data. Standard registered claims include:

• iss (issuer) – who created the token
• sub (subject) – who the token is about
• exp (expiration) – when the token expires (Unix timestamp)
• iat (issued at) – when the token was created
• aud (audience) – intended recipient of the token

You can also add custom claims like role, email, or permissions. Just don't put sensitive data here — remember, the payload is readable by anyone.

3. Signature

The signature is created by taking the encoded header, the encoded payload, a secret key, and the algorithm specified in the header. For HS256:

HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

This signature is what prevents tampering. If anyone modifies the header or payload, the signature won't match when verified.

Common Signing Algorithms

According to a 2025 survey by Snyk, RS256 accounts for 71% of production JWT deployments, followed by HS256 at 22%. ES256 adoption has grown 340% since 2022, driven by mobile and edge computing use cases.

How to Decode a JWT

Decoding a JWT is straightforward because the header and payload are just Base64URL-encoded JSON. No secret key is needed to read them.

The steps:

1. Split the token string at each dot (.) to get three parts
2. Base64URL-decode the first part (header) and parse as JSON
3. Base64URL-decode the second part (payload) and parse as JSON
4. The third part is the signature — decoding it shows raw bytes, not readable JSON

Our JWT decoder does this instantly in your browser. Paste any token and see the decoded header, payload, and expiration status.

JWT Validation Checklist

Decoding is not the same as validation. To properly validate a JWT, your server should:

1. Verify the signature using the correct secret or public key
2. Check expiration — reject tokens where exp is in the past
3. Validate the issuer (iss) matches your expected value
4. Validate the audience (aud) matches your service
5. Check the algorithm — reject none and unexpected algorithms

The OWASP JWT Cheat Sheet lists algorithm confusion as the number one JWT vulnerability. Always validate the algheader against a server-side allowlist, never trust the token's claimed algorithm blindly.

Security Best Practices

Never Store Secrets in the Payload

The payload is not encrypted. A 2024 GitGuardian report found that 6.1% of leaked secrets on GitHub were JWT tokens containing sensitive data like database credentials and API keys embedded in the payload.

Use Short Expiration Times

Access tokens should expire in 5–15 minutes. Pair them with refresh tokens (7–30 days) stored securely. This limits the window of damage if a token is stolen.

Rotate Signing Keys

Use key rotation with kid (key ID) in the header so you can phase out old keys without invalidating all active tokens at once.

Use HTTPS Only

JWTs sent over HTTP can be intercepted. Always transmit tokens over TLS. Set the Secure and HttpOnly flags when storing tokens in cookies.

Beware the “none” Algorithm

Some JWT libraries accept alg: “none”, which means no signature verification at all. This is a critical vulnerability. Always explicitly reject the none algorithm on your server.

Frequently Asked Questions

What is a JWT and what does it stand for?

JWT stands for JSON Web Token. It is an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe JSON object. JWTs are commonly used for authentication and authorization in web applications, APIs, and single sign-on systems.

Can I decode a JWT without the secret key?

Yes. The header and payload of a JWT are only Base64URL-encoded, not encrypted. Anyone can decode and read them. The secret key is only needed to verify the signature, which proves the token has not been tampered with. This is why you should never store sensitive data like passwords in a JWT payload.

What is the difference between HS256 and RS256?

HS256 (HMAC-SHA256) uses a single shared secret for both signing and verification. RS256 (RSA-SHA256) uses a private key to sign and a public key to verify. RS256 is preferred for distributed systems where multiple services need to verify tokens without sharing a secret. According to Auth0, RS256 is used by over 70% of production JWT implementations.

How long should a JWT expiration time be?

Access tokens should expire in 5 to 15 minutes for most applications. Refresh tokens typically last 7 to 30 days. The OWASP Application Security Verification Standard recommends access token lifetimes under 15 minutes. Shorter expiration windows reduce the damage from token theft but require a robust refresh token flow.

Is it safe to decode JWTs in the browser?

Decoding the header and payload in the browser is safe since that data is not encrypted anyway. However, never verify signatures client-side using your secret key, as that would expose the key. Signature verification should always happen server-side. Our JWT decoder runs entirely in your browser and never sends your token to any server.