JWTTokenBase64URLAuthentication

What Is a JWT and How Do You Safely Inspect Header and Payload?

A JWT has three parts: Header, Payload, and Signature. Header and Payload are Base64URL encoded, not encrypted, so anyone with the token can decode them.

ToolGarden tools prioritize browser-local processing, so files and text do not need to be uploaded to a server.

Published July 2, 2026Updated August 3, 20267 min readBy ToolGarden

JWTs are often used for authentication and API authorization, but they are not encrypted containers. Header and Payload can be decoded directly.

xxxxx.yyyyy.zzzzz
header.payload.signature

A JWT usually has three dot-separated parts: Header, Payload, and Signature.

What Do the Three Parts Mean?

Part	Contains	Encrypted?
Header segment	Algorithm and token type, such as alg and typ	No
Payload segment	Claims such as sub, exp, and role	No
Signature segment	A signature calculated with a secret or private key	Used for integrity

Safety Rules for Inspecting JWTs

Do not paste real production tokens into untrusted websites.
Do not store passwords, identity numbers, payment data, or other sensitive values in Payload.
Being able to read Payload does not mean the token is valid; expiration and signature still matter.
HS256 verification requires a secret; never expose a production secret to frontend code or third-party pages.
Browser-local decoding is better than uploading sensitive tokens to a server-based tool.

Common Claims

Claim	Meaning	What to check
sub	Subject or user ID	Is it the expected user?
exp	Expiration time	Usually a Unix timestamp
iat	Issued-at time	Is the token too old?
aud	Audience	Is it meant for this service?
iss	Issuer	Does it come from the expected authority?

Decoding and verification are different operations

Decoding only restores the first two Base64URL segments as JSON and requires no key, so an attacker can create a plausible-looking Payload too. Verification must happen on the server with an allowed algorithm and trusted key, followed by checks for exp, nbf, iss, aud, and other claims. A debugging tool showing the fields proves only that the token is readable, not that it deserves trust.

decoded successfully != valid signature
valid signature != authorized request

complete decision = signature + time + issuer + audience + application permissions

Important server-side verification boundaries

Configure the allowed algorithms on the server instead of accepting any alg named by the Header.
exp and nbf normally use Unix seconds, and comparisons may need a small allowance for clock skew.
Asymmetric algorithms such as RS256 verify with a public key, while HS256 requires every verifier to possess the same secret.
Token revocation, user suspension, and permission changes do not rewrite an old token automatically, so sessions need a separate policy.
A signature protects against content modification. It does not hide the Payload or prove that the client device is safe.

For debugging, use a redacted token or inspect Header and Payload locally. Production keys do not belong in browser code, screenshots, support tickets, or third-party pages. When a real signature must be tested, use the same verification library and algorithm allowlist in a controlled backend or local development environment.

Summary

JWT Header and Payload are convenient for debugging, but they are not private. Safe JWT usage depends on signature keys, expiration, and careful claim design.

Frequently asked questions

Q.Is the JWT payload encrypted? Can I store a password in it?

The payload is Base64Url encoded, not encrypted. Anyone with the token can paste it into a browser console, decode it and read everything. Never put passwords, national ID numbers, payment PINs or full card numbers there. Payloads should hold identifiers such as user ID, role, tenant ID and expiry timestamps. If you truly need to transport sensitive data, use JWE (JSON Web Encryption) which actually encrypts the payload, or keep the sensitive fields on the server and let the JWT carry only an opaque identity reference.

Q.What should the frontend do when a JWT expires? Should it refresh on its own?

Use an access token plus refresh token pair. The access token is short-lived (15 minutes to a couple of hours) and calls your APIs. The refresh token is longer-lived and only used to obtain new access tokens. When a request returns 401 and the refresh token is still valid, silently call the refresh endpoint and replay the original request. Do not rely on a single long-lived token, because a leak grants indefinite access. Avoid frontend polling to refresh eagerly, as clock drift can silently log users out.

Q.When should I choose JWT over a session cookie?

Session cookies rely on server storage. Logout is simple, security is well understood, but horizontal scaling and cross-origin usage are painful. JWTs are stateless, natural for microservices and multiple clients, but revocation is hard and usually requires a short expiry or a blocklist. Rule of thumb: for a single backend serving one web app on one origin, prefer session cookies. For multiple services, mobile plus web, or cross-origin flows, prefer JWT. A hybrid also works, where JWTs face external clients and short-lived signed tokens run inside the mesh.

Q.People say JWT is insecure. Are they exaggerating?

Not exaggeration, but not the whole story either. The real problems are almost always misuse: putting sensitive data in the payload, accepting alg: none, using a short or leaked secret, embedding the secret in the frontend, storing the token in localStorage where XSS can steal it, or forgetting to check exp. Used properly, JWT is safe: choose a strong algorithm (HS256 or RS256), keep the key long, carry only non-sensitive identifiers, ship it via HttpOnly cookie or a short-lived access token, and always verify the signature and expiry.

Q.If Base64 decoding is enough, why do I need a dedicated JWT tool?

Decoding the payload is only step one. A good tool converts iat, exp and nbf into local time; shows how long until the token expires; highlights the signing algorithm; verifies the signature when you paste a secret or public key; and labels common claims. Raw Base64 tells you what is inside but not whether the token is still valid or has been tampered with. When investigating login bugs or reproducing production issues, a dedicated inspector saves significant time compared to a generic decoder.