~/tools/-jwt-decoder-
Token tool - JWT Decoder

$ Decode JWT tokens safely

Inspect JWT header and payload locally. No token upload, no external API calls.

// controls

JWT token

Paste a JWT to decode its header and payload.

Decode only — no signature verificationThis tool reads the header and payload sections of a JWT. It does not validate the signature or expiry. All processing happens in your browser.
vultio · -jwt-decoder-

Decoded output

Paste a JWT token to see its contents.

—
§ 01
context

Why this tool exists

Vultio JWT Decoder splits a JSON Web Token into its three parts and decodes the header and payload sections directly in your browser.

JWTs are base64url-encoded JSON objects. Decoding them reveals claims like user ID, roles, expiry time, and the signing algorithm — useful for debugging authentication flows without needing a backend.

That makes this tool valuable when login succeeds in one environment but fails in another, when an API says a token is expired, or when a role-based access check behaves differently than expected.

The key distinction is that decoding helps you inspect structure and claims, not prove trust. Seeing a payload is useful for debugging, but it does not verify the signature or guarantee the token was issued by the system you think it was.

§ 02
scenarios

Common use cases

01 →Inspect JWT claims (sub, exp, iat, roles) returned by an auth server during development.
02 →Quickly verify the algorithm field in the header before troubleshooting signature errors.
03 →Decode a token from a failing API request to check expiry or missing claims.
04 →Understand the structure of tokens issued by third-party OAuth providers.
05 →Teach JWT format and structure in documentation or security training materials.
06 →Inspect staging vs production tokens to confirm whether claim shape or issuer metadata changed between environments.
§ 03
examples

Example input / output

Minimal token

$ input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
↳ output
// Header { "alg": "HS256", "typ": "JWT" } // Payload { "sub": "1234567890", "name": "Alice", "iat": 1516239022 }

Read expiry and issuer claims

$ input
Payload claims: {"iss":"https://auth.example.com","aud":"api","exp":1777924800,"scope":"read:users"}
↳ output
Useful checks: issuer = https://auth.example.com · audience = api · exp = 1777924800 · scope = read:users

Spot a role mismatch

$ input
Expected roles claim: ["admin"] · Actual token claim: ["viewer"]
↳ output
Decoded payload shows the token is structurally fine, but the granted role set does not match the access path being tested.
§ 04
troubleshooting

Common errors

! Invalid JWT: expected 3 parts separated by "." but got N.

cause:The input is not a valid JWT. JWTs always have exactly three dot-separated segments.

fix:Ensure you copied the complete token including all three parts. Check for accidental truncation or line breaks.

! Failed to decode header: not valid base64url.

cause:The first segment contains characters outside the base64url alphabet or is otherwise corrupted.

fix:Double-check that you copied the full, unmodified token. Avoid URL-decoding the token before pasting it here.

! Header decoded but is not valid JSON.

cause:The decoded bytes are not a JSON object, which suggests the token is malformed or uses an unusual encoding.

fix:Verify the token source. Standard JWTs always have JSON objects as header and payload.

! The token decodes correctly but auth still fails

cause:Decoding only reveals claims. The token may still be expired, signed with the wrong key, issued for the wrong audience, or rejected by server-side verification logic.

fix:After decoding, verify exp, nbf, aud, iss, and the signing/verification path in the actual auth stack rather than assuming a readable payload means a valid token.

! The payload looks trustworthy because it contains familiar claims

cause:Any string that looks like a JWT can be decoded. Human-readable claims do not prove authenticity on their own.

fix:Treat decoded output as inspection data only. Use proper JWT verification on the server or trusted tooling when authenticity matters.

§ 05
workflow

How developers use it in practice

→ Check time-based claims first

When auth suddenly breaks, exp, iat, and nbf are often the fastest clues. A token can be perfectly structured and still rejected because a clock, lifetime, or refresh flow is wrong.

→ Compare tokens from working and failing sessions

A side-by-side claim comparison often reveals missing audience values, different issuers, or altered role scopes much faster than reading auth middleware logs alone.

→ Use decoded output to improve docs and support handoff

Showing the exact header and payload shape helps frontend, backend, and support teams align on what the token is supposed to contain without sharing signing secrets.

§ 06
tradeoffs

When not to use this tool

01 →Do not use a decoder as a replacement for signature verification when security decisions depend on authenticity.
02 →Do not paste highly sensitive production bearer tokens into screenshots, tickets, or shared chats after decoding them.
03 →Do not assume every token-like string is a standard JWT; some systems use opaque tokens that should be introspected differently.
§ 07
limits

Limits and implementation notes

~ Decode and verify are different operations

The browser can decode base64url JSON locally, but trust still depends on cryptographic verification in the real auth system.

~ Claims still need context

Knowing that aud or scope exists is useful, but only your application documentation can tell you whether the values are correct for a specific route or action.

~ Opaque auth flows may need other tools

If a provider uses introspection endpoints, encrypted tokens, or custom envelope formats, decoding alone will not answer the whole debugging question.

§ 08
read more

Related guides

§JWT Decoder Online: The Complete GuideHow to decode JWT tokens online, read claims and headers, understand JWT structure, and debug authentication issues.→§JWT Decoder Security Notes: Decode vs VerifyWhat JWT decoding shows, what it does not prove, and safe debugging practices.→
§ 09
references

Standards & references

↗RFC 7519 – JSON Web Token (JWT)The IETF standard defining JWT structure, claims, base64url encoding, and how header/payload/signature sections are assembled.↗↗jwt.io – Introduction to JSON Web TokensA practical introduction to JWT structure, the three parts of a token, common claims, and when to use JWTs in authentication flows.↗↗OWASP – JSON Web Token Cheat SheetSecurity guidance for implementing JWTs safely: algorithm confusion attacks, key management, and token validation best practices.↗
§ 10
toolbox

Related tools

→Base64 Encoder / DecoderEncode text to Base64 or decode Base64 back to plain text, entirely in the browser.→→JSON FormatterFormat raw JSON to make it easier to inspect.→→Secret GeneratorGenerate passwords, API keys, and JWT secrets.→
§ FAQ
questions

Frequently asked questions

Does JWT Decoder verify signatures?

No. This tool decodes the JWT header and payload only. It does not validate the signature, expiry, or issuer. For security-critical verification, use a proper JWT library.

Is my JWT token sent to a server?

No. The token is decoded entirely in your browser using Base64 decoding. No token data is transmitted anywhere.

What claims can I inspect?

You can inspect all standard claims including iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at), and any custom claims in the payload.

How do I know if my JWT is expired?

The exp claim is a Unix timestamp. Compare it to the current time to determine if the token has expired. The decoder shows the raw exp value you can check.

What JWT algorithms are supported?

The decoder reads any JWT regardless of algorithm (HS256, RS256, ES256, etc.) since it only decodes the header and payload, not verifies the signature.