JWT Decoder

Decode a JSON Web Token's header and payload.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

This decoder splits a JSON Web Token into its header and payload and shows the claims in readable form, so you can check expiry, scopes, issuer and subject without hand-decoding Base64URL.

How to use it

1Paste the full token — three dot-separated segments.
2Read the decoded header and payload.
3Check the exp claim to see whether the token has expired.

Example

Input: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ...
Output: alg: HS256 · name: "John Doe" · iat: 1516239022

Decoding shows the contents; it does not verify the signature, which needs the key.

What happens to your data

This tool runs entirely in your browser. Your input is never uploaded to a server, never stored, and never logged. This is the whole point for a JWT: a token is a live credential and should never be pasted into a remote service.

Last updated August 2026

A JSON Web Token (JWT) packs a header, a payload of claims, and a signature into a compact, URL-safe string. This decoder splits a JWT apart and shows the human-readable header and payload — so you can see the claims, expiry, issuer, and subject without hand-decoding Base64URL segments.

It is the fastest way to answer the everyday questions: *Is this token expired? What scopes does it carry? Which user is it for?*

Before you paste anything, work out which of three things you are holding. Three dot-separated segments starting eyJ is a signed JWT, the shape this decoder expects. Five segments is JWE — encrypted, and only the header will tell you anything. A long random string with no dots at all is not a JWT but an opaque reference, meaningful only inside the system that issued it.

The format's real limitation is that a token is a snapshot, not a live answer. Every claim was true at the moment it was signed and nothing has checked since — a revoked role, a suspended account, a changed email are all invisible here, and the token keeps working until its exp regardless.

The common mistake follows from that: treating what you read as the current state of the account, or as something your own code can act on without verifying the signature first. Reading is for a human debugging; decisions belong to a verifier holding the key.

How it works

Toolvore decodes the token's header and payload locally in your browser. Crucially, your token is never sent to a server — decoding a JWT elsewhere means pasting a live credential into someone else's system, which you should never do. Here it stays on your device. Note that decoding does not verify the signature; it reveals the (unencrypted) contents. What comes back is not byte-for-byte what was signed. Each segment is parsed into an object and printed again with two-space indentation, so anything the JSON text carried but the object cannot is lost on the way through: duplicate claim names collapse to the last one seen, and an integer too large for a double — a nineteen-digit account id sitting in sub — comes back quietly rounded. Bytes are read as UTF-8, so an accented name in a claim reads properly rather than as mojibake, and missing Base64URL padding is restored before decoding, so a segment lifted straight out of a log works on its own. The signature is shown exactly as it arrived, undecoded, because it is bytes rather than text — and where the third segment is empty, no signature panel appears at all.

Common use cases

Checking whether an access token has expired (the exp claim)
Inspecting scopes, roles, and permissions carried in a token
Debugging authentication and authorization flows
Confirming the issuer (iss) and audience (aud) of a token
Understanding what data a third-party JWT actually contains
Checking the alg and kid in a header when signature checks start failing after a key rotation
Reading the claims out of a token pasted into a bug report to see which environment issued it

Frequently asked questions

Is it safe to decode a JWT here?＋

Yes. Toolvore decodes tokens entirely in your browser — nothing is transmitted. Still, treat any live token as a secret.

Does this verify the token's signature?＋

No. Decoding shows the contents; verifying the signature requires the secret or public key and is a separate step done on your server.

Is the payload encrypted?＋

No. A standard JWT payload is only Base64URL-encoded, not encrypted — anyone with the token can read it. Never put secrets in a JWT payload.

Why is my token rejected?＋

A JWT must have three dot-separated segments (header.payload.signature). If a segment is missing or malformed, it cannot be decoded.

How do I turn the exp claim into a readable date?＋

The date claims — exp, iat and nbf — are NumericDate: whole seconds since 1970 in UTC, not milliseconds. That factor of a thousand causes most of the confusion. Hand exp straight to a JavaScript Date and you land in January 1970; multiply by 1000 first for the real moment. At a shell, date -r on macOS and date -u -d @ on Linux take the seconds directly. Nothing here converts it for you — the number appears as the issuer wrote it. Verifiers also allow a little clock skew either side, so the exact second is rarely what decides whether a request is accepted.

My token decodes fine but the API still returns 401 — what should I check?＋

Well-formed is not the same as acceptable, and the failures cluster. Check aud against what the API expects, and iss character for character — a trailing slash on the issuer URL is a genuine and common mismatch. Check kid against the keys the verifier holds now: after a rotation, a token signed with the new key fails wherever the JWKS is cached too long. Check exp and nbf against the server's clock rather than yours. Then check you are sending the right token at all, and that the header reads Bearer followed by a single space — a stray newline picked up in a copy is enough to break it.

Why does my token have five parts instead of three?＋

That shape is JWE compact serialisation: protected header, encrypted key, initialisation vector, ciphertext and authentication tag. Only the header is plain, and it names algorithms rather than telling you anything about the user. The payload is encrypted to the recipient's key, so no decoder can open it without that key — which is the point, since JWE is chosen for tokens the client is not meant to read. What is inside is often an ordinary signed JWT once decrypted, and a cty header set to JWT is the hint. A credential with no dots at all is not a JWT but an opaque reference, readable only through the issuer's introspection endpoint.

What is the difference between an ID token and an access token?＋

An ID token comes from OpenID Connect and is addressed to your application: its aud is your client id, and its job is to say who signed in. An access token comes from OAuth 2.0 and is addressed to an API: its aud is that API, and your application is meant to pass it on without reading it. Sending an ID token to an API as a bearer credential is the classic mix-up, and a well-configured API refuses it on the audience check. The reverse bites too — an access token may be opaque, or may change shape after a provider update, because its contents were never a contract with you.

Can someone change the claims in a JWT?＋

Editing the text is trivial; whether the edit survives verification is the real question, and it does not unless the verifier makes one of two known mistakes. The first is trusting the alg in the header, which lets someone set it to none, drop the signature and be believed. The second is algorithm confusion: a token re-signed with HS256 using the public RSA key as the HMAC secret, accepted by a verifier that takes its algorithm from the token instead of from its own configuration. Both are configuration failures rather than flaws in the format. Pin the algorithm you expect, and pick the key yourself by kid from a source you control.

How do you log someone out or revoke a JWT before it expires?＋

You cannot withdraw a token that has already been issued — that is the price of verifying without a lookup, and every workaround puts some state back. Keep exp short, in minutes, and issue a refresh token that is stored and can be cancelled. Or record a jti in a denylist checked during verification, which returns a database call to the hot path for the length of one token lifetime. Or keep a per-user token version, or a logged-out-at timestamp, and reject anything issued before it. Rotating the signing key kills every outstanding token at once — blunt, but the right lever during an incident.

Why is my JWT so long, and what can I do about it?＋

Claims are JSON, and Base64URL adds a third on top of whatever that JSON weighs, so a handful of roles and a couple of URLs grow faster than people expect. Size matters because tokens travel in headers. RFC 6265 asks browsers to support at least 4,096 bytes per cookie, and in practice that figure is the ceiling rather than the floor; proxies and application servers enforce their own limit on total header size and answer with a 431 or a 400 rather than anything about authentication. Trim by dropping claims nothing reads, shortening scope names, referring to groups by id, and leaving anything bulky to a server-side lookup.