What Is a JWT Token? How to Decode JWT Online
JSON Web Tokens show up everywhere in modern web development — login flows, API authorization, single sign-on, microservice communication. Yet many developers treat them as opaque strings, copying them between tools without understanding what is inside. This article breaks down the JWT structure, explains how signing works, and clarifies the single most dangerous misconception about JWTs.
What Is a JWT?
A JWT (pronounced “jot”) is a compact, URL-safe token format defined in RFC 7519. It carries a set of claims — key-value pairs that assert something about a user or a session — in a format that can be verified and trusted by any party that holds the correct key.
A JWT looks like three chunks of Base64url text separated by dots:
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4ifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cEach dot separates a distinct part: header, payload, and signature.
The Three Parts of a JWT
1. Header
The header is a JSON object that declares the token type and the signing algorithm. After Base64url decoding the first segment above, you get:
{"alg": "HS256"}Common algorithms include HS256 (HMAC with SHA-256), RS256 (RSA with SHA-256), and ES256 (ECDSA with P-256). The algorithm tells the verifier which cryptographic method to use when checking the signature.
2. Payload
The payload is a JSON object containing the claims — the actual data the token carries. Decoding the second segment:
{"sub": "1234567890", "name": "John"}Standard claims defined by the spec include sub (subject), iss (issuer), exp (expiration time), iat (issued at), and aud (audience). You can also add custom claims like role, email, or permissions. There is no hard size limit, but JWTs travel in HTTP headers, so keeping them under a few kilobytes is practical.
3. Signature
The signature is what makes the token trustworthy. For HMAC-based tokens, the server computes:
HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)The result is Base64url-encoded and appended as the third segment. When a server receives a JWT, it recalculates this signature using its own copy of the secret. If the result matches, the payload has not been tampered with. If a single character in the header or payload was changed, the signature check fails.
For asymmetric algorithms like RS256, the server signs with a private key and anyone can verify with the corresponding public key — useful when multiple services need to verify tokens without sharing a secret.
JWTs Are Signed, Not Encrypted
This is the most critical point and the source of real security incidents. The header and payload are only Base64url-encoded — not encrypted. Anyone who intercepts a JWT can decode it instantly and read every claim inside: user IDs, emails, roles, permissions.
Signing prevents tampering. It does not prevent reading. If your JWT payload contains "role": "admin", any client-side JavaScript, any proxy, any browser extension can see that value. The signature guarantees that the server issued exactly those claims and that nobody altered them in transit — but confidentiality is not part of the deal.
If you need the payload to be unreadable, you need JWE (JSON Web Encryption), which is a separate standard. In practice, most applications use signed JWTs over HTTPS, which provides transport-layer confidentiality. The danger arises when tokens are logged, stored in URLs, or sent over unencrypted channels.
Common JWT Security Pitfalls
No expiration claim. A JWT without an exp claim is valid forever. If it leaks, there is no automatic way to invalidate it. Always set short expiration times and use refresh tokens for long-lived sessions.
The alg: none attack. Some libraries historically accepted tokens with {"alg": "none"} and skipped signature verification entirely. Modern libraries reject this by default, but you should always explicitly specify which algorithms your server accepts.
Storing JWTs in localStorage. Any XSS vulnerability in your application can read localStorage and steal the token. HttpOnly cookies are a safer default for browser-based applications because JavaScript cannot access them.
Using JWTs as session stores. JWTs cannot be individually revoked without maintaining a server-side blocklist, which defeats the “stateless” advantage. If you need immediate revocation (user logs out, account is compromised), you need server-side session state.
How to Decode a JWT Online
Decoding a JWT is just Base64url decoding — no secret is needed to read the header and payload. Our JWT Decoder splits the token into its three parts, formats the JSON with syntax highlighting, checks the exp claim against the current time, and shows whether the token is expired.
Everything runs entirely in your browser. The token never leaves your machine, which matters when you are debugging production tokens that contain real user data or session information. Pasting a production JWT into an online tool that sends it to a server is a security risk — that token could be replayed to impersonate the user.
Frequently Asked Questions
Can I change the payload of a JWT?
You can decode it, edit the JSON, and re-encode it — but without the signing key, the signature will not match, and any properly implemented server will reject the token. The signature exists precisely to prevent this.
How long should a JWT be valid?
There is no universal answer, but access tokens are commonly set to 5–15 minutes. Refresh tokens can last hours or days but should be stored securely and rotated on use. The shorter the access token lifetime, the smaller the window of exposure if it leaks.
Is JWT the same as OAuth?
No. OAuth 2.0 is an authorization framework that defines how tokens are requested and granted. JWT is a token format. OAuth can use JWTs as access tokens or ID tokens (as in OpenID Connect), but OAuth itself is not tied to any specific token format.
Should I use JWT for my project?
JWTs work well for stateless API authentication and cross-service communication where you want to avoid a database lookup on every request. They work poorly when you need instant revocation, when the payload would be very large, or when you are building a simple server-rendered application where traditional sessions are simpler and more secure.
Understanding what is inside a JWT — and what signing does and does not protect — prevents the kind of security mistakes that lead to real incidents. When you need to inspect a token quickly and safely, our JWT Decoder handles it entirely in your browser, with nothing sent to any server.