JWT Decoder — Decode Any Token, Client-Side, No Data Sent
This tool decodes JSON Web Tokens (JWTs) directly in your browser. Paste a JWT and the tool splits it into its three parts, base64url-decodes the header and payload, and displays the claims in a readable JSON format with human-readable timestamps. No token data is sent to a server. Your authentication tokens, API keys, and session credentials stay on your device. The tool is free, requires no account, and works offline after the page loads.
Decoded client-side only. Your token is never sent to any server.
Paste a JWT token.
RSA and ECDSA verification require a public key and are not supported yet.
How does the JWT Decoder work step by step?
OnSumo JWT Decoder splits your token into header, payload, and signature, decodes each part, and displays human-readable timestamps without sending data to any server.
The JWT decoder splits a JSON Web Token into its three dot-separated components (header, payload, and signature) and base64url-decodes the first two into readable JSON. JWTs are signed, not encrypted by default; anyone with the token can read the header and payload without any key. The header identifies the signing algorithm (HS256, RS256, ES256, etc.). The payload contains the claims: registered claims like iss (issuer), sub (subject), exp (expiration as a Unix timestamp), and iat (issued-at), plus any custom application claims. The tool converts exp and iat Unix timestamps to human-readable UTC dates and flags expired tokens by comparing exp to the current time. The signature is displayed as-is and labeled with whether the algorithm is symmetric (HMAC, where both signing and verification require the shared secret) or asymmetric (RSA/ECDSA, where verification uses the public key). Key assumption: the tool accepts only the standard three-part dot-separated JWS format; JWE (JSON Web Encryption) tokens have five parts and cannot be decoded without the private key. Edge case: tokens with no exp claim never expire and represent a security risk in production systems. The tool flags a missing exp field as a warning so you can identify tokens issued with unbounded lifetimes.
What does a typical JWT Decoder result look like?
Here is how to use the decoder to diagnose a 401 error caused by an expired access token before making a refresh request.
An API returns 401 and you suspect an expired access token. Paste the JWT, check the expiry badge, and read exp in the claim list before you refresh the token.
Frequently asked questions
Common questions about JWT structure, security, expiry checks, and what the decoder can and cannot tell you about a token.
Is my JWT token sent to a server?
No. The decoder runs entirely in your browser. The base64url decoding, JSON parsing, timestamp conversion, and optional signature verification all happen in JavaScript on your device. There is no network request. Verify this with your browser's DevTools Network tab. This matters because JWTs often contain authentication credentials, user identifiers, and role assignments.
Does decoding a JWT verify its signature?
No, not by default. Decoding reads the header and payload without checking the signature. Anyone can decode any JWT without the secret key. Signature verification requires the secret (HMAC) or public key (RSA/EC) and confirms the token was issued by a trusted party and was not modified. Enable the signature verification mode and paste your key to verify.
Is the payload inside a JWT encrypted?
No. The payload is base64url-encoded, which is an encoding scheme, not encryption. Anyone with the token can decode it and read the payload. For confidential claims, use JWE (JSON Web Encryption, RFC 7516) instead of JWT. Most standard JWTs (JWS, signed tokens) are readable by anyone who holds them.
What does \\\"exp\\\" mean and what happens when a JWT expires?
exp is the expiration time claim. It holds a Unix timestamp (seconds since 1970-01-01 00:00:00 UTC) after which the token is no longer valid. Your server should reject tokens where the current time is past the exp value. The decoder shows the exp value as a human-readable date and computes how much time is left or how long ago the token expired.
What is the difference between HS256 and RS256?
Both are signing algorithms. HS256 (HMAC-SHA256) uses a single shared secret: the same key signs and verifies tokens. RS256 (RSA-SHA256) uses a key pair: a private key signs tokens and a public key verifies them. RS256 is more common for multi-service architectures because you can share the public key widely without exposing signing capability. The algorithm is listed in the JWT header under alg.
Why do some JWTs have three parts and some seem to have more?
A standard JWT always has exactly three parts separated by dots: header, payload, signature. If you see a string with five parts (like xxxxx.xxxxx.xxxxx.xxxxx.xxxxx), it is a JWE (JSON Web Encryption) token, not a standard signed JWT. JWE has a different structure. The current tool decodes signed JWTs (JWS) only.
Related tools
These tools pair with the JWT Decoder for tasks that involve JSON payloads, pattern extraction, and URL encoding.
Regex Visualizer — if you need to extract claims, headers, or token fragments with pattern matching, test a regex online before you add it to your auth tooling.
A JSON Web Token has three parts separated by dots. The header says which algorithm was used. The payload carries the claims, like who the user is and when the token expires. The signature proves the token wasn't altered.
The first two parts are just Base64url text. Anyone holding the token can read them. That's by design, and it's also why you shouldn't put secrets in a payload.
Decoding is not verifying
This is the point people get wrong. Decoding shows you what the token says. Verifying checks that the signature is valid and the token can be trusted. A forged token decodes perfectly well.
The decoder can check an HMAC signature if you provide the secret. Your server must always verify before it trusts any claim. Never grant access based on a decoded payload alone.
Reading the claims
Common claims have short names. The sub claim is the subject, usually a user ID. The iat claim is when the token was issued. The exp claim is when it expires. The iss claim names the issuer and aud names the intended audience.
Timestamps are Unix seconds, which are hard to read. The tool turns them into dates and shows an expiry badge so you see right away whether the token is still valid. Expired tokens are one of the top reasons for mysterious 401 errors, so check that first.
HS256 and RS256
HS256 uses one shared secret to both sign and verify. Simple, but every service that verifies must hold the secret. RS256 uses a private key to sign and a public key to verify. Services can check tokens without being able to create them. Larger systems tend to prefer RS256 for that reason.
Why some tokens look different
Not every token you meet is a plain signed JWT. Encrypted tokens, called JWE, have five parts instead of three, and their payload can't be read without a key. If your token has five segments, a basic decoder won't show you the claims.
Your token stays local
Decoding happens in your browser. The token isn't sent to any server. Even so, treat live production tokens with care. Prefer test tokens when you can, and rotate anything you've pasted somewhere you didn't trust.