Free JWT Decoder Online

Paste a token in and a jwt decoder should show you exactly what's encoded inside it — the algorithm, the issuer, the expiration, every claim — without asking you to trust a third party with the token itself. That second part matters more than it might seem: a JWT often carries a live session, a user ID, or a permission scope, and handing it to the wrong web tool is a real exposure. This one decodes entirely inside your browser tab, so the token you paste never crosses the network to reach this site. This guide walks through how the tool works, what a JWT's three segments actually contain, why decoding and verifying are two completely different operations, and what this tool deliberately does not do.

How the JWT Decoder Works

The tool is a single text box that reacts the instant you paste a token, splitting it into its three dot-separated segments and rendering each one in its own color-coded panel.

• Paste the full token — header, payload, and signature together, separated by two periods — into the input box. Malformed input, like a token missing a segment, produces a clear error instead of a silent failure.
• The header panel shows the decoded algorithm and token type, the payload panel lists every claim with human-readable labels next to recognized fields like issuer, subject, audience, and expiration, and the signature panel shows the raw signature segment as-is.
• If the payload contains an exp claim, a banner appears above the panels showing whether the token is currently valid or expired, along with a relative time — "expires in 40 minutes" or "expired 2 days ago" — computed against your own device's clock.
• Each panel has its own copy button, so you can grab just the header or just the payload as formatted JSON without copying the whole token and re-parsing it somewhere else.

For decoding tokens outside a browser session — inside a backend service, a log-processing script, or an automated test suite — the same decode logic is available as an API endpoint documented at /docs, accepting a token string and returning the decoded header and payload as JSON.

Why Developers Decode JWTs

A handful of situations come up constantly where being able to see inside a token quickly saves real time:

• Debugging an authentication failure. A user reports they got logged out unexpectedly, and the fastest way to find out why is pasting their token and checking whether it actually expired, rather than guessing at backend logs.
• Verifying a third-party integration sends the claims you expect. When wiring up an SSO provider or an OAuth flow, decoding a sample token confirms the issuer, audience, and custom claims match what your backend is actually checking for, before you've written a line of verification code.
• Inspecting an API token pulled from browser dev tools. Pasting a token copied out of a request header or a cookie shows you immediately what scope or role it carries, without writing a throwaway script just to base64-decode two segments by hand.
• Checking expiration before reproducing a bug. If a support ticket includes a token, decoding it first tells you whether the issue happened while the token was live or after it had already expired — a distinction that changes where you look for the bug.
• Learning how a JWT is actually structured. For anyone implementing authentication for the first time, pasting a real token and watching the header, claims, and signature separate out visually is a faster way to understand the format than reading the spec cold.

Technical Deep Dive: Decoding a JWT Is Not the Same as Verifying It

A JSON Web Token is three base64url-encoded segments joined by periods: a header describing the signing algorithm and token type, a payload holding the claims, and a signature computed over the first two segments using a secret or private key. Base64url encoding is not encryption — it's a reversible text encoding, the same family as ordinary base64 but using URL-safe characters in place of + and /. That's precisely why anyone, including this tool, can decode the header and payload of a JWT with no key at all: the information inside a standard JWT was never hidden, only encoded and then signed.

Verifying a JWT is a separate operation entirely, and it's the one this tool intentionally does not perform. Verification recomputes the signature using the correct secret (for HMAC algorithms like HS256) or checks it against a public key (for asymmetric algorithms like RS256), and confirms the result matches the signature segment attached to the token. Doing that correctly requires the actual key material — and that key should never be pasted into a third-party web tool, including this one. A tool that asked you to paste your signing secret to "verify" a token would be asking you to hand over the exact material an attacker would need to forge tokens for your entire system. This decoder sidesteps that risk entirely by not asking for it: it shows you the signature segment as raw text and states plainly that verifying it requires the key, which only your own backend should ever hold.

The claims themselves follow a registered vocabulary defined by the JWT specification, though a token can also carry any custom fields an application adds. The common registered claims are:

Claim	Meaning
iss	Issuer — who created and signed the token
sub	Subject — the entity the token is about, typically a user ID
aud	Audience — the intended recipient of the token
exp	Expiration time, as a Unix timestamp
iat	Issued-at time, as a Unix timestamp
nbf	Not-before time — the token isn't valid until this moment
jti	JWT ID — a unique identifier for this specific token

One caveat on the expiration banner: it compares the exp claim against the current time on your own device. If your system clock is significantly off, the banner's expired/valid read could disagree with what your backend — which checks against its own server clock — actually decides when the token is presented.

JWT Decoder vs Writing Your Own Decode Script

Decoding a JWT by hand isn't hard, but there are real tradeoffs to each approach:

• A quick script or REPL one-liner. Splitting on periods and base64url-decoding two segments is a handful of lines in any language, and if you're already in a terminal mid-debug, that can be faster than switching to a browser tab.
• Browser dev tools console. You can decode a token's payload with a couple of lines of JavaScript directly in the console where you copied the token from, without leaving the page — a reasonable shortcut if you're already there.
• A backend framework's built-in JWT library. If you're actually verifying and consuming tokens in production code, use the library your framework already ships rather than any standalone decoder — decoding for a human to read and verifying for your application to trust are different jobs with different tools.
• A dedicated JWT decoder. No terminal, no console, and the claims come back labeled and color-coded rather than as a raw JSON blob you have to visually parse yourself — plus the expiration banner does the "is this still valid" math for you instead of you converting a Unix timestamp by hand.

For a one-off look at a token during debugging, the visual decoder is simply faster to read. For anything your application needs to trust programmatically, that belongs in your backend's verification code, not in a browser tab.

How Your Token Is Processed

This is the part worth being explicit about: the token you paste is decoded entirely by JavaScript running inside your own browser tab. It is never transmitted to this site's servers, never logged, and never stored anywhere outside your current session — the decoding happens the same way it would if you ran the base64url math yourself in a local script. Because JWTs frequently carry session identifiers or user data, that browser-only processing is the reason it's reasonable to paste a real, live token into this tool in the first place; a decoder that sent your token to a server would be a meaningfully different risk.

Questions About Decoding JWTs

If this tool can read the payload without a key, is a JWT actually secure?

Yes, as long as it's used correctly. A JWT's security comes from the signature proving the token wasn't tampered with after issuance, not from hiding the payload. Anyone can read the claims — that's expected and by design — but only someone holding the correct key can produce a signature your backend will accept as valid.

Why does the decoder show my token is expired when I just got it?

Usually a clock mismatch. The expiration check compares the token's exp claim against your device's local clock; if that clock is wrong, or the token was issued with an unusually short lifetime for testing, the banner can show "expired" sooner than expected.

Can I decode a token if I don't know which algorithm signed it?

Yes — decoding doesn't require knowing the algorithm at all. The algorithm is itself part of the decoded header (the alg field), so you'll see it as output rather than needing to supply it as input.

Does this tool work with tokens that don't have an expiration claim?

Yes. The exp claim is common but not mandatory in the JWT spec. If it's absent, the header and payload still decode and display normally — you simply won't see the expiration banner, since there's nothing to compute a countdown against.

Is a refresh token the same format as an access token?

Often, yes — many systems issue refresh tokens as JWTs too, and this decoder will show its structure the same way. Some systems instead issue refresh tokens as opaque random strings with no decodable structure at all, in which case there's nothing here to decode; that's an implementation choice each backend makes independently.

Why does the signature panel just show text instead of "valid" or "invalid"?

Because determining validity requires the signing key, which this tool never asks for and never receives. Showing the raw signature segment alongside an explicit note that verification needs the key is the honest answer here, rather than a green checkmark that would be meaningless without ever checking anything.

Related Tools

A JWT is built from encoding steps you'll run into elsewhere too. The Base64 Encode/Decode tool is useful for manually inspecting a single segment outside the full token context, or for working with base64 payloads unrelated to authentication entirely. Once you've pulled the payload out as JSON, the JSON Formatter helps if you need to reformat or clean it up for a ticket or documentation. Claims like exp and iat are raw Unix timestamps under the hood, and the Unix Timestamp Converter converts those numbers into a readable date if you want to double-check the decoder's relative-time math yourself. And if you're generating a jti or sub claim for a token your own backend will issue, the UUID Generator produces a properly formatted unique identifier to plug into that claim.