Developer 🔒 Runs in your browser — no data sent to servers

JWT Decoder

Decode JSON Web Tokens locally and verify their signature with your secret or public key — nothing leaves your browser.

JWT Token

Secret or public key

Expected issuer (iss) Expected audience (aud)

The key is used in your browser and is never sent anywhere.

Decoded

Header

Payload

Signature

Sign a token of your own to test an endpoint. Everything is computed in this page.

Algorithm Expires in Key ID (optional)

Payload (JSON)

Signing key Secret is Base64

Signed token

The key and the finished token stay in your browser; neither is sent anywhere, and neither is carried in a share link.

Verify this token in your own code. The snippet follows the algorithm in the header.

Language

How to Use

1. Paste a JWT (a string with three parts separated by dots) into the input box. It is decoded as you type.
2. Read the Header and Payload as formatted JSON, and the tables under them, where every field is listed with what it is for.
3. The line above them says whether the token has expired, and exp, nbf and iat appear as dates in your own time zone.
4. To check the signature, paste the secret or public key under the token and press Verify.

Everything runs in your browser; the token and the key are never sent to a server. The tabs below the decoder add two more things: "Build a token" signs a token of your own, and "Code" prints the verification for eight programming languages.

Frequently Asked Questions

Does this tool verify the JWT’s signature?

Yes. Paste the secret (for HS256, HS384 and HS512) or the public key as PEM or JWK (for the RS, PS and ES algorithms) under the token and press Verify. The check runs on your browser’s own WebCrypto, so the key never leaves the page. A token declaring alg "none" is rejected outright, because it carries no signature at all. Decoding on its own still proves nothing — it only shows what a token claims.

Is it safe to paste a real JWT here?

Yes — decoding happens entirely in your browser using JavaScript; the token is never transmitted anywhere. That said, treat access/ID tokens as sensitive and avoid pasting tokens into tools you don't trust.

Why can I read the payload without a secret key?

JWTs are signed, not encrypted (unless explicitly using JWE). Anyone can decode the header and payload — the signature only proves the token wasn't tampered with, if you have the key to verify it.

What do "exp", "iat", and "nbf" mean?

They're standard JWT claims: "iat" (issued at) is when the token was created, "exp" (expiration) is when it stops being valid, and "nbf" (not before) is the earliest time it becomes valid. This tool converts these Unix timestamps into readable dates automatically.

What if I get a decode error?

Make sure you pasted the complete token with all three parts (header.payload.signature) and that nothing was cut off or altered. Extra whitespace or line breaks can also cause errors — try removing them.

How do I decode a JWT in Python or JavaScript?

In JavaScript use the jwt-decode package: jwtDecode(token). In Python use PyJWT: jwt.decode(token, options={"verify_signature": False}). Both read the payload without verifying it; pass the key to verify.

How do I know when a JWT expires?

Read the exp claim: it is a Unix timestamp in seconds. Convert it with the timestamp converter and compare it to the current time on the server, not on your laptop - a few minutes of clock drift is a common cause of surprise expiries.

Why is my token rejected even though it decodes fine?

Check exp against the server clock, then aud and iss against what the API expects. A mismatched audience is the most common cause of a 401 with a valid-looking token.

Can I create a token here as well?

Yes. The "Build a token" tab under the decoder signs a token with any of the twelve algorithms — HS, RS, PS and ES in three sizes each. Choose the algorithm, edit the payload, paste the shared secret or a PKCS#8 private key, and press "Sign token". The signing runs on your browser's own WebCrypto, so the key stays in the page.

JWT Decoder - Decode a JSON Web Token Online

Updated September 24, 2026 · By Saman

Paste a JSON Web Token and this decoder splits it into its three parts and shows the header and payload as readable JSON. It is the fastest way to answer the questions that come up during authentication debugging: who issued this token, who is it for, which algorithm signed it, and has it already expired?

The decoding happens entirely in your browser. That matters more here than for most tools, because a JWT is a live credential - anyone who captures a valid token can usually act as its subject until it expires. Nothing you paste on this page is uploaded, logged or stored.

A JWT is three Base64URL strings joined by dots. The header and payload are plain JSON that anyone can decode, so a token must never carry secrets. Only the signature, checked with the key, shows that the token has not been changed.

What is a JSON Web Token?

A JWT is three Base64URL segments joined by dots: header.payload.signature. The header names the signing algorithm, the payload carries the claims - the facts the issuer asserts about the user or client - and the signature proves that the first two parts were produced by someone holding the key. Because the header and payload are only encoded, not encrypted, anybody can read them. Only the signature is protected.

How to decode a JWT here

Copy the token from your Authorization: Bearer header, a cookie, a callback URL or your API client.
Paste the full header.payload.signature string into the input field.
Click Decode to see both JSON objects laid out.
Check exp first if the request was rejected, then aud and iss.

What else this page does

The token is read as you type, so the panes fill in before you reach for the button. Under the decoded header and payload every field is listed in a table with what it is for in plain words, and a line above them turns exp and nbf into sentences: expired three days ago, expires in fifty-eight minutes, not valid yet.

Sample loads a demo token and its secret, so you can watch a verification succeed before pasting anything of your own.
Verify takes the secret, a PEM public key, a single JWK or a whole JWKS. Paste the document from the issuer's /.well-known/jwks.json address and the key named by the token's kid is chosen for you, so the page still makes no request of its own. Fill in Expected issuer and Expected audience as well, and a valid signature is checked the way a server checks it: a different iss, or an aud that does not contain your value, turns the result red.
Build a token signs a token of your own with any of the twelve algorithms — the JWT generator page opens on it.
Code prints the server-side verification in eight languages, following the algorithm in your token’s header.
Two more pages open this tool pointed at a single question: has it expired and why is it being rejected.

The standard claims and what they mean

Claim	Meaning	Why it fails
`iss`	Issuer - who created the token	Mismatch when a staging token is sent to production
`sub`	Subject - usually the user or service ID	Empty in tokens issued for a client rather than a person
`aud`	Audience - the API meant to accept it	The single most common cause of a valid-looking 401
`exp`	Expiry as a Unix timestamp	Already in the past, or the server clock has drifted
`nbf`	Not valid before this time	Token used a few seconds too early
`iat`	Issued at	Used for maximum age policies and revocation windows
`jti`	Unique token ID	Needed to blocklist a single token

Decoding is not verifying

This is the point that trips people up. Reading a token tells you what it claims; it does not tell you whether those claims are genuine. Verification means recomputing the signature with the issuer's secret or public key and comparing it, plus checking expiry and audience. Any decoder can show you the payload of a forged token just as happily as a real one, so never make an authorisation decision on decoded content alone - always verify server-side with a maintained library.

Troubleshooting a token that will not work

401 with a valid token: compare aud with what the API expects, and iss with the configured issuer URL. Put both into Expected issuer and Expected audience and press Verify: the result names the value the token really carries.
Expired immediately: convert exp with the Unix timestamp converter and compare it to the server clock, not your laptop's.
Invalid segment error: the token was truncated, URL-encoded on the way, or a newline crept in during copy-paste.
Signature verification fails: the key rotated, the wrong key ID was used, or the token was signed by a different environment.
alg is none: reject it. That value marks an unsigned token and is a classic attack against sloppy validation.

Security habits worth keeping

Never store personal data, internal IDs or anything confidential in the payload - it is readable by design.
Keep access tokens short-lived and use a refresh token for longer sessions.
Transmit tokens over HTTPS only, and prefer secure, HttpOnly cookies over browser storage where you can.
Rotate signing keys on a schedule and publish them through a JWKS endpoint so clients can follow.
Treat any token you have pasted into an online tool as potentially exposed - which is exactly why this one never sends it anywhere.

Runs offline in your browser

The decoder is client-side JavaScript. Once the page has loaded, you can decode tokens with no network connection at all, and production credentials never leave your machine.

Decode a JWT in code or on the command line

Where	How
JavaScript (npm)	`import { jwtDecode } from 'jwt-decode'; jwtDecode(token)` - payload only, no verification
Python (PyJWT)	`jwt.decode(token, options={'verify_signature': False})` to read it, or pass the key to verify
Bash	`echo $TOKEN \| cut -d. -f2 \| tr '_-' '/+' \| base64 -d 2>/dev/null` - Base64URL drops padding, so a short payload may need `==` appended
Browser console	`JSON.parse(atob(token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/')))`

Every one of these reads the token without checking the signature, which is fine for debugging and wrong for authorisation - see the section above.

Related tools

Tokens sit in the middle of a stack of formats. Read the raw segments with the Base64 decoder, tidy the payload with the JSON formatter, turn exp and iat into dates with the timestamp converter, and unescape a token pulled from a URL with the URL decoder.

Guides

Base64 vs Base64URL: What Changes and When to Use Each Base64URL is standard Base64 with two characters replaced, - for + and _ for /, and usually without the = padding. JWT vs Session Cookies: How They Differ and When to Use Each A session cookie is a key to state kept on the server; a JWT carries signed state to the server. That one difference drives every trade-off.