What Is a JWT?

Quick Answer

A JWT (JSON Web Token) is a compact, signed token that carries information as JSON. It has three parts separated by dots: a header, a payload, and a signature. The header and payload are only encoded, not encrypted, so anyone can decode and read them.

If you just need to read what is inside a token right now, paste it into the tool. It decodes entirely in your browser.

What Is a JWT?

A JSON Web Token is a standard way (defined in RFC 7519) to represent claims securely between two parties. A "claim" is just a piece of information, such as who the user is, when the token was issued, and when it expires. Servers use JWTs to prove that a request comes from a logged-in user without having to look the session up in a database on every request.

A JWT looks like one long string with two dots in it:

xxxxx . yyyyy . zzzzz

Those three sections are the header, the payload, and the signature. The first two are JSON objects that have been Base64URL encoded, which is why they look like random text but decode back to readable JSON.

The Three Parts

Each section of a JWT has a distinct job:

• Header: a small JSON object that names the signing algorithm (alg, for example HS256 or RS256) and the token type (typ, which is JWT).
• Payload: the JSON object holding the claims, such as the subject (sub), the issuer (iss), and timestamps for when the token was issued and when it expires.
• Signature: a cryptographic value created from the header, the payload, and a secret or private key. It lets the server confirm that nobody altered the token in transit.

This tool Base64URL-decodes the header and payload and pretty-prints the JSON. It also lists the registered time claims as readable dates, and it shows the raw signature segment without checking it.

Common Registered Claims

The JWT standard reserves a short list of claim names so that different systems agree on their meaning. These are the ones you will see most:

• iss (issuer): who created and signed the token.
• sub (subject): who or what the token is about, such as a user id.
• aud (audience): who the token is intended for.
• exp (expiration): the time after which the token is no longer valid.
• nbf (not before): the earliest time the token may be used.
• iat (issued at): when the token was created.
• jti (JWT id): a unique identifier for the token.

The time claims (exp, nbf, iat) are Unix timestamps measured in seconds. The decoder converts each one to a human-readable date and a relative time, and it marks the token as expired when exp is in the past.

Decoding Is Not Verifying

This is the single most important idea to understand about JWTs. Reading a token and trusting a token are two separate things.

Decoding simply Base64URL-decodes the header and payload so you can read them. It needs no key and proves nothing about whether the token is genuine. Anyone can decode any JWT.

Verifying recomputes the signature using the secret (for HMAC algorithms like HS256) or the public key (for asymmetric algorithms like RS256) and compares it to the signature in the token. Only a matching signature proves the token is authentic and unaltered, and only then should the claims be trusted.

Where You Will Meet JWTs

• Login sessions: after you sign in, an app hands your browser a JWT access token that it then sends with each request.
• API authorization: a token in the Authorization: Bearer header tells an API who is calling and what they may do.
• Single sign-on and OpenID Connect: identity providers issue ID tokens as JWTs that carry profile claims about the user.
• Service-to-service calls: backend services pass signed tokens to prove their identity to one another.

Common Mistakes

This Decoder vs Other Options

There are three common ways to read a token, and they differ mainly in where the decoding happens and what the token is exposed to.

• A server-backed online decoder: some popular tools send the token to a backend or load remote scripts. That is convenient, however it means your token leaves your machine. For a production or staging token, that is a real risk.
• Decoding by hand: you can split the token on the dots and run each segment through a Base64URL decoder yourself. This works, therefore it is a good learning exercise, but it is slow and it does not humanize the timestamps or flag expiry.
• A library in your code: packages like jose or jsonwebtoken decode and, more importantly, verify tokens. Use these in your application. For a quick manual inspection while debugging, a library is more setup than you need.

This tool sits in the gap between those: it decodes instantly, humanizes the claims, and, because the page is static with no backend, the token never leaves your browser. For example, you can paste a live access token to check its expiry without trusting a remote service. When you need to verify rather than read, reach for a library on your server instead.

Related Tools

• Base64 Encoder & Decoder: decode an individual token segment by hand.
• JSON Formatter: pretty-print and inspect the decoded payload.
• SHA-256 Hash Generator: explore the hashing that underlies HMAC signatures.