JWT Decoder & Encoder · Security
Decode, verify and sign JSON Web Tokens in your browser.
Paste a header.payload.signature token to read its claims and verify the signature against a secret, PEM, JWK or JWKS — or flip a tab to sign your own token and generate test keys. Nothing ever leaves the tab.
JWT Decoder & Encoder playground
Results update as you type — press Enter to run now.
Treat pasted keys and secrets as live credentials — clipboard history and screenshots can leak them.
Everything stays in your browser — nothing is sent anywhere. Verifies HS/RS/PS/ES 256–512 and EdDSA against a shared secret, a PEM BEGIN PUBLIC KEY, a JWK, or a full JWKS (matched by kid).
Snapshots save only the token (never keys) to this browser's localStorage — nothing leaves your machine.
No share links on this tool — inputs may be secrets.
Paste a JWT or pick an example to see its header, payload, claims, and signature decoded here.
Treat pasted keys and secrets as live credentials — clipboard history and screenshots can leak them.
Signing happens in your browser with the Web Crypto API — keys never leave this page. The token is built from minified JSON, so whitespace in the editors never changes the signature. Need a key? Use the Generate keys tab.
Fill in the header, payload, and key to see the signed token here.
Generated locally with the Web Crypto API — nothing leaves your browser. Great for tests and local development; production keys belong in your platform's KMS or secret manager.
Pick a key type and press Generate — the key appears here as PEM and JWK, with copy buttons.
The Gap
A token is just three strings — until one claim is wrong.
Debugging auth means staring at an opaque eyJ… blob and guessing. Is the token expired? Is the audience right? Did the issuer sign it with the key you think it did? The answers are all in there — base64url-encoded, one dot away — but reading them by eye is error-prone, and many online decoders quietly POST your token to a server. The same goes for AI assistants: a token pasted into a chat lands in a third party’s conversation history — and possibly its training pipeline. Never paste a production token into an AI chat. Decode it locally instead.
This JWT workbench turns the blob into the concrete facts you need — the header algorithm, every claim with a plain-English caption, the human-readable expiry — and, when you supply the secret, public key, JWK or JWKS, confirms the signature with the Web Crypto API across all thirteen JWS algorithms. It also goes the other way: edit the header and payload JSON, sign a fresh token, or generate an RSA / EC / Ed25519 test key pair — all fully client-side, so it is safe to use even with production tokens.
Need the raw bytes instead? The Base64 Encoder / Decoder handles arbitrary base64 and base64url payloads.
The Pipeline
How it works.
Five deterministic steps run on every keystroke — all inside your browser tab, with signing and verification handled by the Web Crypto API.
-
Split the token.
The compact JWT is split on its two dots into the header, payload and signature segments.
-
Decode the parts.
The header and payload segments are base64url-decoded back into their original JSON objects.
-
Read the claims.
Standard claims are surfaced with plain-English captions, and exp, nbf and iat are turned into readable times with an expiry check.
-
Verify the signature.
Supply a secret, PEM public key, JWK or JWKS and the HS / RS / PS / ES / EdDSA signature is recomputed and checked locally.
-
Sign your own.
Flip to Encode & sign to mint a token from editable JSON — or generate a fresh test key pair first.
Token Reference
Anatomy of a JWT.
Three base64url segments joined by dots. The header and payload are JSON; the signature is computed over the first two and is what verification re-checks.
header.payload.signature
The two dots split the token into three parts. The signature covers the header.payload bytes — change either and it no longer matches.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 ← header (base64url JSON)
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6... ← payload (base64url JSON)
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQ ← signature (base64url bytes)
header . payload . signature
└─────── signed input ──────┘ ⇒ signatureCommon claims
A legend for the registered header and payload fields. Times such as exp are NumericDate — seconds since the Unix epoch.
alg header signing algorithm, e.g. HS256 / RS256
typ header token type, usually "JWT"
kid header key id — which key signed this token
iss payload issuer — who created the token
sub payload subject — who the token is about
aud payload audience — who the token is for
exp payload expiration time (NumericDate, seconds)
nbf payload not-before time (NumericDate, seconds)
iat payload issued-at time (NumericDate, seconds)
jti payload unique token idNext Step
Got the bytes? Encode, decode and hash them.
Once a token reads correctly, drop down a level: the Base64 Encoder / Decoder handles the base64url payloads JWTs are built from, and the Hash Generator computes the SHA digests that sit behind HMAC signing — both entirely in your browser.
HMACSHA256(
base64url(header) + "." +
base64url(payload),
secret
) ⇒ signature ✓FAQ
Questions, answered.
Tap a question to expand the answer.
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe credential made of three base64url parts separated by dots: a header, a payload of claims, and a signature — written as header.payload.signature. The header names the signing algorithm, the payload carries claims such as who the token is for and when it expires, and the signature lets the recipient confirm the token was issued by a trusted party and has not been tampered with. JWTs are widely used as access and ID tokens in OAuth 2.0 and OpenID Connect.
Does my token or secret ever leave the browser?
No. Decoding and any signature verification run 100% client-side in your tab — there is no server, no account, no logging and no network request. The token you paste and the secret or public key you supply stay in memory in this page and are never uploaded. You can decode tokens offline.
Is the signature actually verified — and how?
Yes, optionally and locally. Paste a shared secret for an HMAC token (HS256 / HS384 / HS512) or a public key for an asymmetric one — RS256–512, PS256–512, ES256–512, or EdDSA — and the tool recomputes the signature over the header.payload bytes using the Web Crypto API right in your browser, then reports valid or invalid. The key can be a PEM "BEGIN PUBLIC KEY" block, a single JWK, or a full JWKS (the right key is picked by the header kid). If you leave the key blank it simply decodes without checking the signature.
Can this tool create and sign a JWT, too?
Yes. Switch to the "Encode & sign" tab, edit the header and payload JSON, pick an algorithm, and supply a secret (for HS256/384/512) or a PKCS8 private key / private JWK (for RS, PS, ES, or EdDSA). The token is signed live in your browser with the Web Crypto API — nothing is generated on a server. There is also a "Generate keys" tab that mints test HMAC secrets and RSA / EC / Ed25519 key pairs, exported as both PEM and JWK.
Which signing algorithms are supported?
All thirteen JWS signature algorithms that browsers can do natively: HS256, HS384 and HS512 (HMAC), RS256, RS384 and RS512 (RSASSA-PKCS1-v1_5), PS256, PS384 and PS512 (RSA-PSS), ES256, ES384 and ES512 (ECDSA on P-256, P-384 and P-521), and EdDSA (Ed25519, in browsers that support it). Unsigned alg:"none" tokens are decoded — with a warning — but never created here, and ES256K (secp256k1) is not available in the Web Crypto API.
Is it safe to generate signing keys in a browser?
For development and testing, yes: the keys come from the Web Crypto API’s cryptographically secure generator, are created entirely on your machine, and are never transmitted or stored by this page. For production, generate and hold keys in your platform’s KMS, HSM, or secret manager instead — a browser tab has no secure storage story, and anything rendered on screen can end up in screenshots or clipboard history.
What do the exp, nbf and iat claims mean?
They are standard registered claims expressed as NumericDate (seconds since the Unix epoch). exp (expiration time) is the instant after which the token must be rejected; nbf (not before) is the instant before which it must not be accepted; iat (issued at) is when the token was created. The decoder converts each to a readable UTC time and flags whether the token is currently expired or not yet valid.
Is it safe to paste a production token here?
Decoding happens only in your browser, so nothing is transmitted — but a JWT is still a live credential. Treat it like a password: only paste a token you control, prefer a short-lived or test token, and remember that the payload is merely base64url-encoded, not encrypted, so anyone holding the token can read its claims. Rotate or revoke a token if you suspect it has been exposed anywhere. That caution applies doubly to AI chatbots: treat any token pasted into a chat window as exposed, and rotate it.
Are JWT tokens encrypted, or just encoded?
Standard signed JWTs are not encrypted — the header and payload are only base64url-encoded, so anyone who has the token can read its claims without any key. The signature proves the token was not tampered with, but it does not hide the contents. Because of this, you should never store passwords, personal data, or secrets inside JWT claims.
Can you decode a JWT without the secret key?
Yes. Reading the header and payload requires no key at all because the data is only base64url-encoded. The secret or public key is needed only to verify the signature — to confirm the token genuinely came from the expected issuer. This decoder lets you inspect the claims whether or not you supply a key.
How do I check if a JWT token is expired online?
Paste the token into the JWT Decoder and look at the exp claim row. The tool converts the raw Unix timestamp to a readable UTC date and automatically flags the token as expired if the current time has passed the exp value. The iat (issued at) and nbf (not before) claims are shown with their human-readable dates as well.
Does decoding a JWT verify or validate the token?
No. Decoding only reveals the contents of the header and payload — it does not prove the token is authentic. To validate a token you must verify its signature using the secret or public key from the issuer. This tool can perform that check locally in the browser, but for authorization decisions the signature must always be verified server-side before trusting any claim.
More free, private DevOps tools.
The JWT Decoder & Encoder is one tool in OpsCanopy — a growing canopy of browser-based validators, converters and testers that never touch a server.
More in Security
29 free tools, every one offline-capable — opscanopy.com works with no signup and nothing uploaded.
More security & encoding: the Hash Generator and the Base64 Encoder / Decoder, or turn the exp, nbf and iat epoch claims into readable dates with the Timestamp Converter — or browse the full tools directory.
Provided as-is for convenience; a JWT is a live credential, so always handle and store tokens securely. OpsCanopy is free and open.