If you've ever opened your browser's dev tools and seen an authorization header full of dot-separated gibberish like eyJhbGciOi..., you've seen a JWT. They're everywhere in modern web authentication — and understanding what's actually inside one is a genuinely useful debugging skill.
What Is a JWT?
JWT stands for JSON Web Token — an open standard (RFC 7519) for compactly representing claims (pieces of information) between two parties, most commonly used to prove a user is logged in after authenticating. A JWT is a string made of three base64url-encoded parts separated by dots: header.payload.signature.
- Header: metadata about the token, such as the signing algorithm (e.g.
{"alg":"HS256","typ":"JWT"}). - Payload: the actual claims — data like the user ID, roles, and an expiration time (e.g.
{"sub":"1234567890","name":"Jane Doe","exp":1755504000}). - Signature: a cryptographic signature computed from the header, payload, and a secret or private key, used to detect tampering.
Servers issue a JWT after a successful login, the client stores it and sends it back with subsequent requests, and the server checks the signature to confirm the token is still valid and untampered.
Decoding vs. Verifying — Not the Same Thing
This is the single most important thing to understand about JWTs: the header and payload are only base64url-encoded, not encrypted. Anyone who has the token — including a browser extension, a tool like ours, or an attacker who intercepted it — can decode and read the header and payload without any secret key.
Decoding just reverses that encoding to show you the readable JSON inside the header and payload. It requires no key and proves nothing about whether the token is authentic.
Verifying is a completely different, cryptographic operation: it recomputes the signature using the secret (for HMAC algorithms like HS256) or checks it against a public key (for RSA/ECDSA algorithms like RS256), and confirms it matches the signature in the token. Only the party holding that secret or key can verify a token — a generic decoder tool cannot, because it never has access to your server's signing secret.
In short: a decoder answers "what does this token claim?" A verifier answers "can I trust this token?" You need the second one before making any authorization decision — never trust a JWT's contents just because a decoder was able to read them.
How to Decode a JWT Online, Step by Step
- Go to utilityx.co.in/text-tools/jwt-decoder/
- Paste your JWT string into the input box
- Instantly see the decoded header and payload as readable JSON
- Check the expiry status, which is calculated from the payload's
expclaim
The UtilityX JWT Decoder runs entirely in your browser — your token is never sent to a server, which matters because JWTs frequently contain identifying information about a real logged-in user. As the tool itself makes clear, this is a decoding tool only; it does not and cannot verify a signature.
Common JWT Payload Claims
| Claim | Meaning |
|---|---|
sub | Subject — usually the user ID |
iat | Issued at — Unix timestamp of creation |
exp | Expiration — Unix timestamp after which the token is invalid |
iss | Issuer — who created the token |
aud | Audience — who the token is intended for |
Debugging tip: if a user reports being unexpectedly logged out, decode their JWT and compare the exp timestamp to the current time using a timestamp converter — an unexpectedly short expiry is one of the most common causes.
Frequently Asked Questions
Is decoding a JWT the same as verifying it?
No. Decoding only reads the header and payload, which are base64url-encoded but not encrypted — anyone can read them. Verifying checks the signature against the secret or public key to confirm the token hasn't been tampered with. A decoder tool cannot verify a signature without that secret or key.
Can anyone read the contents of a JWT?
Yes. The header and payload of a JWT are only encoded, not encrypted, so anyone with the token can decode and read them. Never put secrets or sensitive personal data directly in a JWT payload.
What does the "exp" claim in a JWT mean?
The "exp" claim is the token's expiration time, stored as a Unix timestamp. Once the current time passes this value, a properly implemented server should reject the token even if its signature is otherwise valid.
Why do JWTs have three parts separated by dots?
The three parts are the header, payload, and signature. Splitting them this way lets any party quickly separate and decode the readable header/payload sections while keeping the signature distinct for cryptographic verification.
Summary
A JWT is a compact, self-contained token made of a header, payload, and signature, commonly used to represent an authenticated session. Decoding reveals the header and payload instantly — but only signature verification, done with the correct secret or key, actually proves a token is authentic and untampered.
Need to inspect a token right now? Use UtilityX JWT Decoder — free, private, and browser-based.