JWT Decoder — View JSON Web Token Payload

Decode JSON Web Token headers and payloads locally. A jwt token viewer for inspecting claims at a glance, with no upload and no signature check.

Work in your browser

Local and private
Decoding does not verify the token signature or prove that its claims are trustworthy.

How to use JWT Decoder — View JSON Web Token Payload

Three simple steps, with your content kept on your device.

01

Paste a JWT

Add a compact token containing header, payload, and signature segments.

02

Decode locally

Read the Base64URL header and payload as formatted JSON.

03

Inspect claims

Review algorithm, issue time, expiration, and payload values.

Built for useful work

Fast, focused, and made to be clear on every screen.

Formatted JSON

View decoded token sections with readable indentation.

Claim summary

See common algorithm, issued-at, and expiration values.

No token upload

Sensitive token text remains inside your browser.

What is a JWT?

A JWT, or JSON Web Token, is a compact token used to pass claims between parties — most often to identify a user in an API session. It looks like three dot-separated Base64URL segments, each hiding a JSON object.

The three parts are the header, which describes the signing algorithm; the payload, which carries the claims; and the signature, which proves the token was produced by whoever holds the secret key.

How the JWT decoder works

The decoder splits the token at the dots, decodes the header and payload from Base64URL, and presents them as readable JSON. The claim summary highlights common values such as the algorithm, issued-at, and expiration times.

This is a parser and debugger: it reveals what the token contains. Sensitive token text remains inside your browser and is never uploaded.

Decoding is not verifying

Decoding only reveals the header and payload. Anyone can create or modify an unsigned payload, so a decoded JWT is not trustworthy on its own.

Signature verification requires the correct key and the expected algorithm, which this tool does not perform. Trust claims only after proper signature, issuer, audience, and time validation on your side.

Header, payload, and signature

The header states the type and algorithm, typically HS256 or RS256. The payload holds the claims — subject, issuer, audience, and expiry. The signature is a hash of the first two segments signed with the secret key.

Inspecting all three parts with a JWT parser makes it easy to understand why a token was rejected: an expired exp claim, a wrong audience, or an unexpected algorithm all show up at a glance.

Security notes for debugging tokens

Tokens may contain sensitive data, which is why this decoder works locally and never uploads the token. Treat decoded claims the same way you would treat the raw token.

This tool handles the common three-part signed JWT format, not encrypted JWE tokens, which use a different structure.

Debugging authentication problems

When an API rejects a request, the JWT token is often the first thing to inspect. Decoding it shows the expiry time, the issuer, the audience, and the algorithm — the fields that typically cause 401 responses.

A JWT debugger workflow is straightforward: paste the failing token, read the decoded claims, and check whether exp is past, aud matches the API, or the algorithm differs from what the server expects.

Working with tokens safely

Tokens can carry user identifiers and other sensitive claims, so decode them in a private tab or local tool rather than pasting them into shared services. This decoder runs entirely in your browser for that reason.

Never paste a production token into a third-party website. Local decoding gives you the same insight without exposing the token to a server.

Common JWT claims explained

The most common claims are exp (expiration), iat (issued at), iss (issuer), aud (audience), sub (subject), and jti (unique token ID). Decoding a token shows these values as readable JSON, making the token's meaning obvious.

A token that fails validation usually fails on one of these: exp is in the past, aud does not match the API, or iss differs from the expected issuer.

Reading a token in development

During development, tokens are generated and rejected constantly. A fast local decoder turns a mysterious 401 into a clear explanation: the token expired five minutes ago, or the algorithm does not match the server configuration.

This workflow is exactly what the tool is built for — paste, decode, read the claims, fix the cause, and move on.

JWT vs opaque tokens

JWTs are self-contained: the claims travel inside the token, so a server can read them without a database lookup. Opaque tokens are random strings that require a server-side store to resolve.

This distinction matters when you decode a token and see claims in plain JSON — that transparency is the main reason developers reach for a JWT decoder during API work.

Frequently asked questions

Does decoding verify a JWT signature?

No. Decoding only reveals the header and payload. Signature verification requires the correct key and expected algorithm.

Is a decoded JWT trustworthy?

Not by itself. Anyone can create or modify an unsigned payload. Trust claims only after proper signature, issuer, audience, and time validation.

Can Valestiom read encrypted JWTs?

No. This tool handles the common three-part signed JWT format, not encrypted JWE tokens.