No — a standard signed JWT (JWS) is encoded, not encrypted. Anyone holding the token can read the header and payload with a Base64 decoder. The signature prevents tampering, not reading. Never put secrets in a JWT payload. Encrypted JWTs (JWE) exist but are far less common.

What are the parts of a JWT?

Three parts separated by dots: a header (the algorithm and token type), a payload (the claims — user ID, expiry, issuer, custom data), and a signature computed over the first two parts with a secret or private key.

What is the exp claim in a JWT?

exp is the expiration time as a Unix timestamp in seconds. After that moment the token must be rejected. Companion claims: iat (issued at) and nbf (not valid before).

Dev Guides

How to Decode a JWT (and What's Actually Inside One)

Q: What is the difference between decoding and verifying a JWT?

Decoding just reverses the Base64 encoding to read the contents — anyone can do it. Verifying recomputes the signature using the issuer's secret or public key to prove the token was not tampered with. Servers must verify; decoding alone proves nothing.

Published Jun 12, 2026 5 min read By Navi Works

A JWT is three Base64url-encoded parts separated by dots — header, payload, and signature — and the first two are readable by anyone. "Decoding" a JWT just means reversing that encoding to see the JSON inside. It requires no secret, no key, and no permission. That surprises a lot of people, and it is the single most important thing to understand about JWTs: they are signed, not hidden.

To see inside a token right now, paste it into the free JWT Decoder — it splits and pretty-prints all three parts entirely in your browser, so the token never leaves your device.

Anatomy of a JWT

A real token looks like this (colored by part):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsZXgiLCJpYXQiOjE3NjU1NTU1NTUsImV4cCI6MTc2NTU1OTE1NX0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Part	Contains	Decoded example
Header	Algorithm + token type	`{"alg":"HS256","typ":"JWT"}`
Payload	Claims — IDs, expiry, roles, custom data	`{"sub":"1234567890","name":"Alex","exp":1765559155}`
Signature	HMAC or RSA/ECDSA signature over header + payload	(binary — not JSON)

The claims you'll meet most often

sub — subject, usually the user ID
iss — issuer, who minted the token
aud — audience, who the token is for
exp — expiry as a Unix timestamp (seconds)
iat / nbf — issued-at and not-before timestamps
Anything else — custom claims: roles, permissions, tenant IDs, feature flags

How to Decode One (Step by Step)

Open the JWT Decoder

Go to the naviwork.tools JWT Decoder. It is client-side only — nothing you paste is sent anywhere.

Paste the token

The tool splits it on the dots and Base64url-decodes the header and payload into formatted JSON.

Read the claims

Check exp to see if the token is still valid (it's a Unix timestamp — the Timestamp Converter turns it into a date), and look at sub, iss, and any custom claims to understand what the token grants.

Safety note: a JWT is a live credential — treat it like a password. Decode production tokens only in client-side tools, never in anything that posts your token to a server, and never share screenshots of live tokens.

Decoding ≠ Verifying (This Is the Part That Matters)

Decoding reads the token. Verifying proves it hasn't been tampered with, by recomputing the signature with the issuer's secret (HS256) or public key (RS256/ES256) and comparing it to the third part.

Anyone can decode. The payload is plain Base64url — readable by any holder of the token.
Only key-holders can verify. Without the secret or public key, you cannot tell a genuine token from a forged one.
Servers must verify every request. Trusting a decoded-but-unverified token is the classic JWT vulnerability — an attacker just edits the payload, re-encodes it, and hopes nobody checks the signature.

So: use a decoder to debug — to see why a login fails, check an expiry, or inspect claims. Use a proper JWT library with signature verification to authenticate.

Frequently Asked Questions

Is it safe to paste a JWT into an online decoder?

Only if the decoder runs entirely in your browser. A JWT is a live credential — anyone who captures it can impersonate you until it expires. The naviwork.tools decoder is client-side only; your token never leaves your device.

Is a JWT encrypted?

No — a standard signed JWT is encoded, not encrypted. Anyone holding it can read the header and payload. The signature prevents tampering, not reading. Never put secrets in a JWT payload. (Encrypted JWTs — JWE — exist but are far less common.)

What's the difference between decoding and verifying?

Decoding reverses the Base64 encoding to read the contents — anyone can do it. Verifying recomputes the signature with the issuer's key to prove integrity. Servers must verify; decoding alone proves nothing.

What is the exp claim?

The expiration time as a Unix timestamp in seconds. After that moment the token must be rejected. iat (issued at) and nbf (not before) are its companions.

Why does my decoded JWT show garbled text?

Usually the token was truncated in copy-paste (they're long), or it's not a JWT at all — opaque session tokens and API keys aren't decodable. A real JWT always has exactly two dots and starts with eyJ (the Base64url encoding of {").

Decode a JWT Now

Paste a token, see the header and payload as formatted JSON. 100% client-side — your token never leaves the browser.

Open JWT Decoder