What Is JWT? How JSON Web Tokens Work

A JWT (JSON Web Token) is a compact, URL-safe token — defined by RFC 7519 — that carries a set of claims (small pieces of data, like a user ID or an expiration time) between two parties as a signed JSON object. It's the token format behind most modern API authentication and stateless session handling.

What Is JWT?

A JWT packages claims into three Base64URL-encoded, dot-separated segments: a header, a payload, and a signature. The header and payload are just JSON — readable by anyone who has the token, not encrypted — and the signature lets a server confirm the header and payload haven't been altered since they were signed, provided the server checks that signature against the correct key.

That last part matters: a JWT only proves anything once its signature is actually verified. Simply being able to read a JWT's contents (which anyone can do, including you, with our JWT Decoder) tells you nothing about whether it's authentic.

How Does JWT Work?

In a typical flow:

1. A server authenticates a user (e.g., checks a password) and issues a JWT, signing it with a secret key (HMAC) or a private key (RSA/ECDSA).
2. The client stores that JWT and sends it with subsequent requests, usually in an Authorization: Bearer <token> header.
3. The receiving server re-computes the signature over the header and payload using the key it has, and compares it to the signature segment in the token.
4. If the signatures match and the claims (like exp) pass their checks, the server treats the request as authenticated — without needing to look up a session in a database.

That last point is what makes JWTs attractive for APIs and microservices: any service holding the right verification key can validate a token independently, with no shared session store.

JWT Structure: Header, Payload & Signature

A compact JWT is three Base64URL segments joined by dots:

header.payload.signature

Header

A small JSON object declaring the token type and the signing algorithm, for example:

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

alg tells a verifier which algorithm to use when checking the signature — HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA), and similar values defined in RFC 7518 are the common ones.

Payload

The claims themselves — the actual data the token is carrying, for example:

{ "sub": "1234567890", "name": "Ada Lovelace", "iat": 1716239022, "exp": 1716242622 }

Signature

Computed over the encoded header and payload using the algorithm named in the header, plus a secret or private key. It's what makes tampering detectable — change one character of the payload and the signature no longer matches, so any verifier checking it will reject the token. The signature itself is not decoded like the header and payload; it's just compared byte-for-byte during verification.

What Are JWT Claims?

Claims are the key-value pairs inside the payload. RFC 7519 registers a small set of standard ("registered") claim names with specific meanings:

Claim	Name	Meaning
iss	Issuer	Who created and signed the token
sub	Subject	The identity the token is about (typically a user ID)
aud	Audience	Who the token is intended for — a verifier should reject a token whose aud doesn't match it
exp	Expiration Time	A NumericDate (seconds since the Unix epoch) after which the token must be rejected
iat	Issued At	A NumericDate marking when the token was created
nbf	Not Before	A NumericDate before which the token must not be accepted yet
jti	JWT ID	A unique identifier for this specific token, often used to prevent replay

None of these are required by the spec — an application can issue a JWT with only the claims it needs — and any application is free to add its own custom claims (like role or permissions) alongside the registered ones. For a deeper look at expiration handling specifically, see JWT Expired: What the exp Claim Means & How to Fix It.

Are JWTs Encrypted?

No — a standard JWT is signed, not encrypted. The header and payload are Base64URL-encoded JSON, which is trivially reversible by anyone, not a form of encryption. That means:

• Anyone holding the token can read every claim inside it.
• The signature only protects integrity (detecting tampering) — it does nothing to keep the contents secret.

If you actually need to hide the payload's contents from the token holder or anyone intercepting it, standard signed JWTs (technically called JWS) are the wrong tool — you'd need JWE (JSON Web Encryption, RFC 7516), a related but distinct format that produces a five-segment encrypted token instead of a three-segment signed one. In practice, most systems avoid putting genuinely sensitive data (passwords, secrets, full financial details) in a JWT payload at all, encrypted or not, and instead keep the token to identifiers and non-sensitive claims.

How to Decode a JWT

Because the header and payload are just Base64URL-encoded JSON, decoding a JWT doesn't require a secret key, a library, or a server round-trip — it's a purely mechanical reversal of the encoding. Paste any token into our JWT Decoder and it will instantly show you the decoded header, the decoded payload, the expiration status, and the raw signature segment — entirely in your browser, with nothing sent anywhere. It's a decoder, not a verifier: it will show you what a token claims, not whether those claims are cryptographically authentic.

JWT Security Basics

A few things worth internalizing before you build anything on top of JWTs:

• Signature verification is what makes a JWT trustworthy — decoding alone proves nothing. Any client-side or manual inspection of a token's contents is for debugging, not authorization.
• Expiration matters. Short-lived tokens limit how long a stolen token stays useful; pair short access-token lifetimes with a refresh-token flow rather than issuing long-lived tokens for convenience.
• The payload is readable by anyone holding the token. Don't put passwords, raw secrets, or anything you wouldn't want exposed in client-side storage into JWT claims.
• HTTPS still matters. A signature stops tampering, but it does nothing to stop someone intercepting the token in transit and reusing it — that's what TLS is for.
• The algorithm in the header must be checked, not just trusted. A verifier that blindly trusts whatever alg a token claims (including none, which means "no signature at all") opens the door to forged tokens; this is a well-known class of implementation bug, not a flaw in JWT itself.

Common JWT Mistakes

• Treating decoding as verification. Being able to read a token's claims says nothing about whether it's genuine — only a proper signature check against the correct key does that.
• Storing sensitive data in the payload assuming it's hidden. It isn't, unless you're specifically using JWE.
• Issuing tokens that never expire, or that expire so far in the future that a leaked token stays dangerous for months.
• Ignoring aud and iss. Without checking these, a token issued for one service can sometimes be replayed against another that trusts the same signing key.
• Manually editing a token's payload to "test" something in production. Any change breaks the signature immediately, and treating a decoder's read-only output as something safe to hand-edit and resubmit is a common source of confusing, hard-to-debug errors.

Frequently Asked Questions

What does "JWT" stand for, and how is it pronounced?

JWT stands for JSON Web Token, defined by RFC 7519. It's commonly pronounced "jot," though plenty of people just say the initials.

Is a JWT the same thing as an OAuth access token?

Not necessarily. An OAuth access token can be formatted as a JWT, but it doesn't have to be — some authorization servers issue opaque, random-string access tokens instead. JWT is a token format; OAuth is a separate authorization framework that can choose to use that format. See our full comparison in JWT vs OAuth.

Can a JWT be revoked before its expiration time?

Not on its own. A JWT is self-contained and stateless — once issued, any server holding the right key can verify it until it expires, with no built-in mechanism to invalidate it early. Revoking a JWT before its exp requires extra infrastructure, like a server-side denylist or a short expiration paired with a refresh-token flow that checks a database on each renewal.

Do I need a special library to create or read a JWT?

To decode and read one, no — the header and payload are just Base64URL-encoded JSON, so any Base64URL decoder works (ours does this automatically). To create a JWT or cryptographically verify its signature, yes — you need a JOSE/JWT library in your language that implements the signing algorithm in the header correctly.

What's the difference between JWS and JWE?

JWS (JSON Web Signature, RFC 7515) is what produces a standard signed JWT — the format almost everyone means when they say "JWT." JWE (JSON Web Encryption, RFC 7516) is a separate, less common format that encrypts the payload instead of just signing it, producing a five-segment token rather than three.

Why do some JWT claims use short three-letter names?

RFC 7519 registers short names like iss, sub, exp, iat, and nbf specifically to keep the encoded token compact, since the claim names themselves take up space in every token issued. Nothing stops an application from adding its own longer, custom claim names alongside them.