JWT Decoder
Decode a JSON Web Token and inspect its header and payload. Signatures are not verified.
Short answer: Paste a JSON Web Token to instantly read its decoded header and payload — the signing algorithm, issuer, expiry time, and custom claims — without sending the token anywhere. Decoding happens entirely in your browser, so the token never leaves your device.
Last updated: October 13, 2026
Runs entirely in your browser — nothing you paste is uploaded or stored.
How it works
A JSON Web Token is three Base64URL-encoded parts joined by dots: header.payload.signature. The header describes the token type and signing algorithm; the payload carries the claims (the actual data); the signature proves the token was issued by someone holding the secret key.
Paste a token and this decoder converts the first two parts back into readable JSON as you type, so you can inspect who issued the token, when it expires, and what it claims. It deliberately does not verify the signature — decoding lets you look inside a token, but only your server, checking the signature with the proper key, can decide whether to trust it.
A worked example
The sample token loaded in the tool is the well-known demo JWT. It decodes to this header:
… and this payload — a subject (sub), a name, and an issued-at timestamp (iat):
Frequently asked questions
Does this tool verify the token signature?
No. It decodes the header and payload so you can read them. Verification requires your application secret or public key and must happen on your server before any claim in the token is trusted.
Is it safe to paste a real token here?
Decoding happens entirely in your browser — nothing is transmitted or stored. Still, treat tokens like passwords as a habit: avoid pasting live production tokens into any tool you do not fully control.
What do claims like sub, iat, and exp mean?
They are standard registered claims: sub is the subject (usually a user ID), iat is the issued-at time, exp is when the token expires, and iss names the issuer. Times are Unix timestamps in seconds.
Why will my token not decode?
A JWT must have exactly three dot-separated parts, and the first two must be valid Base64URL containing JSON. Truncated tokens, stray whitespace inside the token, or non-JSON content will fail.
What is the difference between decoding and verifying?
Decoding is just reading — anyone holding a token can decode it, which is why tokens must never contain secrets. Verifying is checking the signature to prove the token is authentic and unmodified.
What do "exp" and "iat" mean?
"exp" is the expiry time and "iat" is the issued-at time, both as Unix timestamps. This decoder renders them as readable dates — an "exp" in the past is the most common reason a token gets rejected.
Can this tool verify the token's signature?
No, and it does not try. Verification needs the signing secret or public key, which a browser tool should never ask for. Decoding shows you the contents; only the issuing server can confirm authenticity.
Is it safe to paste my token here?
On this page, yes — decoding runs entirely in your browser and the token never leaves your device. As a general habit, though, treat tokens like passwords and avoid pasting live production tokens into sites you do not trust.
What is base64url encoding?
A URL-safe variant of base64 that uses "-" and "_" instead of "+" and "/", so encoded data survives in URLs and headers without further escaping. JWTs use it for all three of their dot-separated parts.
Reading a JSON Web Token
A JWT is three parts separated by dots: header.payload.signature. Each part is base64url-encoded — like base64, but with URL-safe characters so the token can travel in headers and query strings without mangling. Decoding simply reverses that encoding to reveal the JSON inside; it does not check whether the token is authentic.
The header
The header is small and boring by design. It names the token type ("typ": "JWT") and, more importantly, the signing algorithm in "alg" — commonly HS256 (one shared secret) or RS256 (a public/private key pair). The algorithm tells a server how to verify the signature, which is a separate step from reading the contents.
The payload: claims
The payload carries claims — statements about the user and the token itself. The registered claims you will see most often are iss (who issued the token), sub (who it is about, usually a user id), aud (who it is intended for), exp (expiry as a Unix timestamp), iat (issued-at), and nbf (not valid before). This decoder converts those timestamps into human-readable dates, which is the fastest way to answer "why was my token rejected?" — an exp in the past is the usual culprit. Anything else in the payload is a custom claim the issuing application defined, such as roles or permissions.
The signature — and what this tool does not do
The signature proves the token has not been tampered with, but verifying it requires the secret or public key, which a browser tool does not have and should not ask for. So this decoder shows you the signature without verifying it. As a rule, treat tokens like passwords: they grant access to whoever holds them. Pasting a live production token into any website is a risk — the reason this decoder runs entirely in your browser is precisely so your token never leaves the page.
Is it safe to paste my JWT into an online decoder?
Decoding only reads the token; it doesn’t verify the signature or grant access to anything. Still, treat tokens like passwords: a production access token pasted into any website is exposed to that site’s code.
This decoder runs 100% in your browser — your token is never transmitted — which makes it safe for development tokens. For production secrets, prefer a local tool or your framework’s debugger, and use short-lived test tokens when experimenting.
What do the header, payload, and signature sections mean?
A JWT has three dot-separated parts. The header names the signing algorithm (like HS256) and the token type. The payload carries the claims — standard ones like iss (issuer), exp (expiry), and sub (subject), plus whatever custom fields your service added. The signature lets the server verify nothing was tampered with.
Note that the payload is only base64-encoded, not encrypted: anyone holding the token can read it. Never put sensitive data like passwords or personal details in claims.