What Is a JWT Token? Structure, Claims & How to Decode One

TL;DR

• → A JWT has three parts: header, payload, and signature — separated by dots.
• → The payload is readable by anyone. The signature proves it hasn't been tampered with.
• → Decode any JWT instantly with the free JWT Decoder.

If you've ever built or called an API that uses authentication, you've almost certainly dealt with JWTs. They show up in Authorization headers, cookies, and local storage — three dots separating what looks like gibberish. Here's exactly what they contain and how they work.

What JWT Stands For

JWT stands for JSON Web Token. It's an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. The information is verified and trusted because it's digitally signed — either with a secret (HMAC) or a public/private key pair (RSA or ECDSA).

The Three Parts of a JWT

A JWT looks like this:

Three Base64url-encoded segments, separated by dots:

• →Header — Specifies the token type (JWT) and the signing algorithm used (HS256, RS256, etc.). Always decode this first if you're debugging an unknown token.
• →Payload — Contains the claims — statements about the user and metadata. This is the useful part: user ID, email, roles, expiry time. It is not encrypted — anyone with the token can read it.
• →Signature — The cryptographic proof. Created by signing the encoded header + payload with a secret key. The server uses this to verify the token hasn't been modified.

Common JWT Claims

The JWT spec defines several registered claim names. You'll see these in almost every token:

Beyond these registered claims, applications add their own custom claims — things like role: "admin", email: "user@example.com", or permissions: ["read", "write"].

How to Decode a JWT

Because the header and payload are just Base64url-encoded (not encrypted), you can decode them without any key. The ToolStack JWT Decoder pastes any JWT and instantly shows you the decoded header, payload with all claims, and the signature algorithm — all in your browser with no data sent to a server.

To decode manually: split the token on the dots, take the first two segments, and Base64url-decode each one. You'll get readable JSON. The third segment (signature) is binary and only useful for verification.

How JWT Authentication Works

The typical flow in an API:

• 1User logs in with their credentials (username/password).
• 2Server validates credentials, then creates a JWT signed with a secret key and returns it.
• 3Client stores the JWT (memory, localStorage, or a cookie) and sends it in the Authorization header on subsequent requests: Authorization: Bearer <token>.
• 4Server receives the request, extracts the token, verifies the signature using its secret key, and checks the exp claim. If both pass, the request is authenticated.
• 5No database lookup needed — the user's identity and permissions are self-contained in the token.

JWT Security: What Not to Do

• →Never store sensitive data in the payload — The payload is readable by anyone with the token. Don't put passwords, SSNs, or private keys in there.
• →Use short expiry times — If a token is stolen, it can be used until it expires. Keep exp at 15–60 minutes for access tokens. Use refresh tokens for longevity.
• →Validate the algorithm — The alg field in the header should always be validated server-side. The infamous 'alg: none' attack exploits servers that trust whatever algorithm the token specifies.
• →Use HTTPS only — Tokens sent over plain HTTP can be intercepted. Always use HTTPS in production.

Frequently Asked Questions