JWT Decoder Tool
Decode and inspect JSON Web Tokens without sending them to any server. See the header, payload, and verify the token structure. All processing happens in your browser.
What Gets Decoded
- Header: Algorithm (HS256, RS256) and token type
- Payload: Claims including user data, expiration, issuer
- Signature: Displayed but not verified (needs secret key)
Common JWT Claims
- iss: Issuer (who created the token)
- sub: Subject (who the token is about)
- aud: Audience (intended recipient)
- exp: Expiration timestamp
- iat: Issued at timestamp
- nbf: Not before (token not valid before this time)
Security Reminders
- JWT payload is Base64 encoded, NOT encrypted. Anyone can read it.
- Never put sensitive data (passwords, SSN) in JWT payload
- Always verify signatures on the server side
- Check expiration before trusting a token
- Use short expiration times (15-60 minutes for access tokens)
What Exactly Is a JWT Decoder?
If you've spent any time working with modern web APIs or authentication systems, you've almost certainly encountered a JSON Web Token — a compact, URL-safe string that looks something like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV6Sl0ogv9U. That wall of characters isn't gibberish — it's structured data, base64url-encoded and split into three parts. A JWT Decoder is the tool that cracks that open and shows you what's actually inside, in plain human-readable JSON.
These tools live online and work entirely in your browser. You paste in a JWT, click decode, and instantly see the header, payload, and signature segments laid out cleanly. No installation, no setup, no backend call (in most reputable implementations). For developers debugging auth flows, frontend engineers wondering why a user's session expired, or security folks auditing token contents, a JWT decoder is genuinely indispensable.
The Three Parts Every JWT Decoder Reveals
Understanding what a decoder actually shows you makes the tool far more useful. Every JWT has three base64url-encoded segments separated by dots:
- Header: Typically declares the token type (
JWT) and the signing algorithm — most commonlyHS256(HMAC-SHA256) orRS256(RSA with SHA-256). When you decode a token and see"alg": "none", that's a serious red flag worth investigating immediately. - Payload: The actual claims — who the user is, what permissions they hold, when the token expires (
exp), when it was issued (iat), and any custom data your application added. This is the part most people care about day-to-day. - Signature: A cryptographic signature that proves the token hasn't been tampered with. Most online decoders show the raw signature bytes but cannot verify them without the secret key — an important distinction.
Frequently Asked Questions About JWT Decoders
People come to JWT decoders with a surprising range of questions. Here are the ones that come up constantly, answered directly.
Is it safe to paste my JWT into an online decoder?
This depends entirely on the token's contents and the tool you're using. The payload of a JWT is not encrypted — it's merely base64url-encoded, which anyone can reverse. So the question is really: what sensitive data does your token carry, and do you trust the site not to log it? For production tokens containing user IDs, emails, or role claims from a live system, use a local decoder or a well-audited tool that explicitly states it does no server-side processing. For testing tokens with fake data, any reputable online decoder is fine. Never paste tokens from your production environment into random websites.
Can a JWT decoder verify the signature?
Most cannot — and that's by design. Verifying an HMAC-SHA256 signature requires the secret key that the server used to sign the token. An online decoder doesn't have that key, so it can only decode and display the claims. Some advanced tools let you paste in a secret or public key to run verification locally in the browser. If you see a decoder claiming to "verify" tokens without you providing a key, that's worth being skeptical about.
What does it mean when the decoder shows the token is expired?
The exp claim in a JWT payload is a Unix timestamp. A good decoder compares it against the current time and flags tokens that have expired. If you're debugging a "401 Unauthorized" error and the decoder shows your token expired three minutes ago, that's your culprit. The fix is typically to implement proper token refresh logic in your application, or to check why your token lifetime is configured so short on the server.
Why does my payload show numbers instead of a readable date for exp and iat?
Those are Unix timestamps — seconds elapsed since January 1, 1970. The value 1750000000, for example, corresponds to June 2025. Better JWT decoder tools automatically convert these timestamps to human-readable dates right in the interface. If yours doesn't, you can paste the number into any Unix timestamp converter. Knowing the exact expiry time is often the whole reason you opened the decoder in the first place, so this quality-of-life feature matters.
Can I edit the payload in a JWT decoder and regenerate a token?
Some tools offer this as a feature, but be careful about what it actually produces. If you modify the payload and regenerate, you get a new token — but its signature will be invalid unless the tool also has your signing secret. What you'll get is a structurally valid JWT that any proper server will reject during signature verification. This feature is useful for testing how your frontend renders data with different claim values, but it produces tokens that won't pass a real auth check.
My token has four segments instead of three — what's going on?
You're looking at a JWE (JSON Web Encryption) token, not a plain JWT. JWE tokens are actually encrypted, not just encoded, and they have a different five-part structure. A standard JWT decoder won't help you here — you'd need a JWE decryption tool along with the appropriate private key. JWE is less common in everyday web apps but shows up in certain enterprise and OAuth 2.0 flows.
A Practical Debugging Workflow Using a JWT Decoder
Here's a real scenario: your application is throwing 403 errors for a specific user, but only on certain API endpoints. You grab the user's JWT from the Authorization header in the browser's network tab. You paste it into a decoder. The payload reveals the user has "role": "viewer" but the failing endpoints require "role": "editor". Mystery solved — the user's role claim in the database wasn't updated when their permissions changed, so old tokens still carry the stale role. You know exactly where to look now.
This kind of investigation takes about ninety seconds with a decoder. Without one, you're digging through backend logs, guessing, and potentially involving multiple team members for what turns out to be a trivial misconfiguration.
What Separates a Good JWT Decoder from a Basic One
Not all decoders are equal. The features that actually matter in practice:
- Automatic timestamp conversion —
exp,iat, andnbfdisplayed as real dates, not raw numbers. - Expiration status indicator — a clear visual showing whether the token is currently valid, expired, or not-yet-active based on
nbf. - Algorithm highlighting — flagging dangerous algorithms like
noneor weak ones likeHS256in contexts where asymmetric signing would be more appropriate. - Client-side only processing — the page should decode everything in JavaScript without sending your token anywhere. Reputable tools document this explicitly.
- Pretty-printed JSON with copy buttons — sounds minor, but when you're staring at deeply nested claims, good formatting saves real time.
Security Habits Worth Building Around JWT Decoding
The ease of decoding JWTs is itself a security reminder: your token payload is readable by anyone who intercepts it. Treat JWTs like session cookies — transmit them only over HTTPS, store them carefully on the client side, and don't stuff sensitive data like passwords, full SSNs, or credit card numbers into claims just because the token feels "secure."
Also worth knowing: the fact that a token decodes cleanly says nothing about whether it's been tampered with. Decoding and validating are different operations. Your server must always verify the signature on every request — a JWT decoder is purely a human inspection tool, not a security mechanism.
When You Need More Than a Decoder
If you're doing deeper JWT work — testing different signing algorithms, generating tokens for test suites, or verifying that your signing library produces correct output — a decoder alone isn't enough. Look for tools that combine decoding with signature verification (where you supply the key) and token generation. The debugging workflow stays similar, but you get the full picture rather than just the decoded claims.
For most day-to-day development needs, though, a solid online JWT decoder handles the job in seconds and gets you back to actually fixing the problem.