JWT Decoder Online: The Complete Guide
Learn how to decode JWT tokens online, read header and payload claims, understand expiry, and inspect token metadata without writing code.
Last updated: May 4, 2026
What is a JWT token?
A JSON Web Token (JWT) is a compact, URL-safe string used to transmit verified claims between parties. JWTs are the most common format for API authentication tokens, OAuth 2.0 access tokens, and SSO session tokens. You will encounter them in the Authorization: Bearer <token> header on almost every modern API.
A JWT consists of three Base64url-encoded parts separated by dots: header.payload.signature. The header describes the token type and algorithm. The payload contains the claims. The signature verifies that the token was not tampered with.
JWT structure decoded
A typical JWT looks like this:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNTAwMDAwMCwiZXhwIjoxNzE1MDg2NDAwfQ.HMAC_SIGNATURE
Decoding reveals:
Header
{ "alg": "HS256", "typ": "JWT" }Payload (claims)
{
"sub": "user_123",
"name": "Alice",
"role": "admin",
"iat": 1715000000,
"exp": 1715086400
}How to decode a JWT online
Step 1 — Copy the JWT token
Copy the full JWT string, including all three dot-separated parts. Common sources: browser dev tools Application tab (cookies, localStorage), Postman response, API response body, or aAuthorization header in a network request.
Step 2 — Paste into the JWT Decoder
Open the JWT Decoder on Vultio and paste the token. The header and payload are decoded instantly. The tool runs entirely in your browser — your token is never transmitted to any server.
Step 3 — Read the claims
Inspect the decoded payload for the claims you need: sub (subject/user ID), exp (expiry timestamp), iat (issued at), iss (issuer), and any custom claims like role or permissions.
Standard JWT claims reference
issWho issued the token (e.g. "https://auth.example.com"). Useful for multi-tenant systems with multiple issuers.
subThe entity the token represents, typically a user ID. This is the primary identifier for the authenticated principal.
audThe intended recipient of the token. Services should verify this matches themselves to prevent token reuse across services.
expUnix timestamp after which the token is no longer valid. Always check this when debugging authentication issues.
iatUnix timestamp of when the token was issued. Combined with exp, tells you the intended token lifetime.
jtiUnique identifier for this specific token. Used to prevent token replay attacks by tracking used tokens.
nbfUnix timestamp before which the token is not yet valid. Rarely used but appears in scheduled or future-dated access grants.
Real-world debugging scenarios
401 Unauthorized — token expired
Decode the token and check the exp claim. Convert the Unix timestamp (e.g. 1715086400) using the Timestamp Converter to see exactly when it expired. If exp is in the past, the token needs to be refreshed.
403 Forbidden — wrong role or scope
Decode the payload and look for role, scope, or permissions claims. The service is likely rejecting the request because the claim value does not meet the required permission level.
Wrong user acting on resource
Check the sub claim to confirm which user the token represents. This is useful when debugging multi-user scenarios where the wrong token may have been used in a request.
Validating algorithm
Decode the header to check the alg claim. Confirm it matches what your server expects. Accepting alg: none is a critical security vulnerability — the header decoder makes it easy to spot this quickly.
JWT decoding vs JWT verification
Decoding reads the content of the header and payload by reversing the Base64url encoding. Anyone can decode any JWT — no key is needed. The data is not secret; only the signature provides integrity.
Verification checks that the signature is valid using the server's secret or public key, and that the token has not expired, is from the expected issuer, and is meant for this audience. Verification requires the secret/key and should only happen server-side.
The JWT Decoder on Vultio only decodes — useful for debugging, but never a substitute for server-side verification in production code.
Frequently asked questions
Is it safe to paste a production JWT into an online decoder?
The Vultio JWT Decoder runs entirely in your browser — no token data is transmitted anywhere. However, as a general practice, avoid pasting production tokens with long expiry times into any online tool. For debugging, use tokens from a test/staging environment when possible.
Can a JWT be decoded without the secret key?
Yes. The header and payload are only Base64url-encoded, not encrypted. Anyone can read them. The secret key is only needed to verify the signature, not to decode the content.
Why does my JWT payload show gibberish?
If the payload decodes to unreadable characters, the token may use an encrypted JWT (JWE) rather than a standard signed JWT (JWS). JWE payloads are encrypted and cannot be decoded without the private key. Standard JWTs are not encrypted — only signed.
How do I check when a JWT expires?
Decode the token, find the exp claim, copy the Unix timestamp value, and paste it into the Timestamp Converter to see the human-readable expiry date and time.
What JWT algorithms are most common?
HS256 (HMAC-SHA256) is the most common for server-to-server tokens with a shared secret. RS256 (RSA-SHA256) is used in OAuth/OIDC flows where the token issuer and verifier are separate systems. ES256 (ECDSA-SHA256) is increasingly preferred for its smaller key sizes and equivalent security.