JWT Decoder — read any JSON Web Token instantly

A JWT decoder takes a JSON Web Token — that long, dot-separated string you see in Authorization headers, cookies, and API responses — and splits it back into the readable JSON it was built from. If you work with authentication in any modern web stack, you've run into a JWT: it's how a server hands a client proof of who they are without a database lookup on every request. The problem is that the raw string is base64url-encoded, not human-readable, so the moment something looks wrong — a login that won't stick, a 401 you can't explain, an integration that silently rejects your token — you need a fast way to see what's actually inside it.

This tool does exactly that, and it does it locally in your browser tab. At Arb Digital we build authentication flows, APIs, and full websites for a living, and a JWT decoder is one of the tools our own engineers reach for daily during debugging — so we built a version that's fast, accurate, and doesn't ask you to paste a token into some third-party server you've never heard of.

What This JWT Decoder Does

Paste any JWT into the box above and the tool splits it on its two dots into three parts: the header, the payload, and the signature. It base64url-decodes the header and payload segments and pretty-prints each as formatted JSON so you can actually read it, instead of squinting at a wall of random-looking characters. It also pulls out the standard time-based claims — iat (issued at), exp (expiration), and nbf (not before) — and converts their Unix timestamps into readable dates, then tells you plainly whether the token is currently valid, not yet active, or expired. The signature itself is shown as-is; this tool intentionally does not attempt to verify it, for reasons explained below.

How to Use It

1. Copy your token. Grab the full JWT string — it should have exactly two dots and look like three chunks of random-looking base64url text separated by periods.
2. Paste it into the input box. A sample token is pre-loaded so you can see the tool working immediately; just replace it with your own.
3. Click Decode Token. The header and payload appear instantly as formatted JSON below, and the status panel shows the algorithm, issued time, expiry time, and whether the token is still valid.
4. Copy what you need. Use the Copy Header or Copy Payload buttons to grab either block for a bug report, a Slack message to a teammate, or your own notes.
5. Check the expiry status. If the token has an exp claim, the tool computes the remaining time and flags it clearly as expired, active, or not-yet-valid based on nbf.

The Structure Behind a JWT Decoder

A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The header is a small JSON object naming the signing algorithm (commonly HS256 or RS256) and the token type. The payload is a JSON object of "claims" — arbitrary data like a user ID, an issuer, an expiration time, or custom fields an application adds. The signature is the output of running the header and payload through the algorithm named in the header, combined with a secret or private key that only the issuing server holds. Base64url is nearly identical to standard base64, but it swaps + and / for - and _ and drops padding characters, specifically so the encoded string is safe to use inside a URL or HTTP header without extra escaping. This structure and its standard claim names — iss, sub, aud, exp, nbf, iat, jti — are defined in RFC 7519, The JSON Web Token specification, and MDN's JWT glossary entry is a solid plain-language companion to it.

Decoding Is Not Verifying — and That Matters

This is the single most important thing to understand about any JWT decoder, including this one: reading the contents of a JWT proves nothing about whether it's genuine. Base64url is an encoding, not encryption — anyone, anywhere, with no key and no special tool beyond a text editor, can decode the header and payload of any JWT they get their hands on. The signature is the only part of the token that actually proves it came from the real issuer and hasn't been tampered with, and checking that signature requires the issuer's secret key (for HMAC algorithms like HS256) or public key (for RSA/ECDSA algorithms like RS256 or ES256) — something a generic decoder deliberately does not have, because if it did, it wouldn't be trustworthy to use on other people's tokens. A server that merely decodes an incoming JWT without verifying its signature is trusting whatever the client claims about itself, which is a serious security bug. Always verify signatures server-side with a proper JWT library before trusting any claim in the payload.

It follows that you should treat the contents of a JWT as visible, not secret. Never put a password, credit card number, or other sensitive value directly into a JWT payload — assume anyone who intercepts the token, or anyone with browser dev tools open, can read every field inside it. And be careful about which tokens you paste into any online tool, including this one: a production access token that's still valid is a live credential. Because this decoder runs entirely client-side with no network calls, nothing you paste ever leaves your machine, but it's a habit worth keeping everywhere — prefer test tokens or expired tokens when you're just debugging structure, and treat live tokens the way you'd treat a password.

Reading the Time-Based Claims

Three claims control a JWT's validity window, and this tool surfaces all of them. iat (issued at) records when the token was created, as a Unix timestamp in seconds since January 1, 1970. exp (expiration time) is the timestamp after which the token must be rejected outright, no exceptions. nbf (not before) is less common but marks a timestamp before which the token isn't valid yet — useful for tokens issued in advance for a future login window. A server-side JWT library checks the current time against both exp and nbf on every request, and this tool mirrors that logic client-side purely for your visibility: it computes "now" against the token's own claims and reports whether you're looking at an active, expired, or not-yet-active token, plus a human-readable countdown or overdue duration.

One subtlety worth knowing: real-world systems rarely trust exp down to the exact second. Clocks drift between servers, and a well-built authentication system allows a small amount of "clock skew" — often 30 to 60 seconds — before rejecting a token as expired, to avoid false rejections caused by two machines disagreeing on the current time by a few seconds. If you're building or debugging an auth flow and a token is being rejected right at its expiry boundary, clock skew tolerance (or the lack of it) is a common culprit worth checking.

Why the Algorithm Field Matters

The header's alg field tells a verifier which algorithm to use, and this innocent-looking field has been the source of real vulnerabilities in poorly written JWT libraries. A well-known attack class involves an attacker changing alg to none or swapping an asymmetric algorithm for a symmetric one, tricking a careless verifier into skipping signature checks entirely. Modern, well-maintained JWT libraries hard-code the expected algorithm on the verifying side rather than trusting whatever the token claims, precisely to close this gap. If you're choosing a library to verify JWTs in your own backend, confirm it lets you pin the exact algorithm you expect rather than reading it from the token itself.

Common Places JWTs Show Up

• Authorization headers — sent as Authorization: Bearer <token> on API requests, the most common transport for stateless API authentication.
• Session cookies — some frameworks store a signed JWT in an HttpOnly cookie instead of a server-side session table.
• OAuth and OpenID Connect flows — ID tokens returned by identity providers like Google or Auth0 are JWTs carrying identity claims.
• Single sign-on and internal service-to-service calls — short-lived JWTs let one microservice prove its identity to another without a shared session store.

Common Mistakes to Avoid

• Trusting a decoded payload without verification. Decoding shows you what a token claims; only signature verification proves it's genuine.
• Pasting live production tokens into random online tools. A valid JWT is a live credential — treat it like a password, and prefer tools that run locally, like this one.
• Assuming exp is in milliseconds. JWT timestamps are Unix seconds, not JavaScript's usual milliseconds — a common off-by-1000 bug when hand-rolling verification code.
• Storing sensitive data in the payload. Anything in a JWT is readable by whoever holds the token; it is not an encrypted container.
• Ignoring clock skew during debugging. A token rejected within a few seconds of its exp boundary may be a clock sync issue, not a bug in your logic.

Related Free Tools From Arb Digital

Working with tokens usually means working with other encoded data too. Try our Base64 Encoder/Decoder for the raw encoding a JWT is built on, the Hash Generator for checksums and integrity checks, the UUID Generator for generating request or session identifiers, and the JSON Formatter for cleaning up any payload you decode here. You can find every tool we've built in the free online tools hub.

Frequently Asked Questions