Developer Tools Blog

JWT Decoding Explained: How to Decode, Verify & Secure Your JSON Web Tokens

📅 July 30, 2026 ⏱️ 7 min read 🏷️ JWT, Security, Authentication

JSON Web Tokens (JWT) power authentication across millions of web applications. Every time you log into a site, there's a good chance a JWT is being exchanged behind the scenes. But when you need to decode a JWT token — whether for debugging, testing, or learning — you need to understand what's inside and how to decode it safely. This guide covers JWT anatomy, decoding methods, and essential security practices.

JWT Anatomy: The Three Parts

A JWT token consists of three Base64-encoded sections separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
                \___ HEADER ___/ \______ PAYLOAD ______/ \_________ SIGNATURE _________/

1. Header

The header typically contains two fields: the token type (typ: "JWT") and the signing algorithm (alg: "HS256" or alg: "RS256"). Decoded, it looks like:

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

2. Payload

The payload contains the claims — statements about the user and additional metadata. Standard claims include:

  • sub — Subject (usually the user ID)
  • iat — Issued At (when the token was created, as a Unix timestamp)
  • exp — Expiration Time (when the token expires)
  • iss — Issuer (who created the token)
  • aud — Audience (who the token is intended for)

3. Signature

The signature is created by combining the encoded header and payload with a secret key, then applying the algorithm specified in the header. The signature verifies that the token hasn't been tampered with — but it cannot be decoded to reveal the secret key.

How to Decode a JWT Token Online (Safely)

Decoding a JWT reveals the header and payload — not the signature. Here's the safe way to do it:

  1. Copy your JWT token — from an Authorization header, browser DevTools, or API response. The token may include a Bearer prefix, which modern decoders handle automatically.
  2. Paste it into a JWT decoder — a browser-based tool is essential. Never paste production tokens into server-based decoders.
  3. Click Decode — the tool extracts and pretty-prints the header and payload as JSON.
  4. Inspect the claims — check the exp timestamp to see if the token is still valid, verify the iss, and read any custom claims.
⚠️ Critical Security Warning: Decoding a JWT only reveals its contents — it does NOT verify the signature. Signature verification requires the secret key or public key, which should only exist on your server. A decoded token could have been tampered with. Always validate JWTs on the server side.

Understanding JWT Claims

When you decode a JWT, you'll see timestamps like "iat": 1516239022. These are Unix timestamps. Use a timestamp converter to translate them into readable dates. A token with "exp": 1516239922 means it expires at that Unix time — if the current time is past it, the token is expired and should be rejected.

JWT Security Best Practices

  • Never store sensitive data in the payload — The payload is Base64-encoded, not encrypted. Anyone who intercepts the token can decode and read it. Never put passwords, credit card numbers, or personal data in JWT claims.
  • Set short expiration times — Use 15-minute access tokens with refresh tokens for longer sessions. This limits the damage if a token is leaked.
  • Always use HTTPS — JWTs are bearer tokens: whoever possesses the token can use it. HTTPS prevents token interception in transit.
  • Validate on the server — Client-side decoding is for debugging only. Real authentication decisions must happen on the server with signature verification.
  • Use RS256 for distributed systems — HS256 uses a shared secret; RS256 uses public/private key pairs, making it safer for microservices where multiple services need to verify tokens.

Need to decode a JWT token right now?

🔓 Open JWT Decoder →