How to decode a JWT

Decoding a JSON web token takes three steps, and this tool handles all of them automatically:

Paste your token. Copy the full JWT — it looks like three base64url strings joined by dots (xxxxx.yyyyy.zzzzz) — and paste it into the input box above. All three dot-separated parts must be present.
The tool splits header, payload, and signature. Each segment is base64url-decoded separately. The header and payload are parsed as JSON and displayed with syntax highlighting. The signature is shown as a raw base64url string; see below for why it cannot be validated here.
Inspect your claims. The claim summary panel surfaces the most useful fields: algorithm (alg), issuer (iss), audience (aud), subject (sub), and the three timestamps (iat, nbf, exp) converted to human-readable local time. EXPIRED and NOT YET ACTIVE banners appear automatically when the current time falls outside the token's validity window.

Because JWTs use Base64 encoding (specifically the URL-safe base64url variant), no padding characters or special keys are required — any valid token decodes instantly without server round-trips.

JWT structure explained

Every JSON web token is composed of exactly three base64url-encoded segments separated by dots. Understanding the structure is the first step in both jwt authentication debugging and security review.

Header

The header is a small JSON object that describes the token type and the signing algorithm. A typical header decodes to:

{"alg":"HS256","typ":"JWT"}

Common alg values: HS256 (HMAC-SHA256, symmetric), RS256 (RSA-SHA256, asymmetric), ES256 (ECDSA-SHA256, asymmetric). The kid (key ID) field, when present, tells a verifier which public key to fetch from the issuer's JWKS endpoint.

Payload

The payload carries the actual claims — statements about the user or session. A typical payload looks like:

{
  "iss": "https://auth.example.com",
  "sub": "user_01HXK9",
  "aud": "https://api.example.com",
  "exp": 1747958400,
  "iat": 1747872000,
  "jti": "f3a2e1d0-5c6b-4a7f-8e9d-0b1c2d3e4f50"
}

The seven registered claims (iss, sub, aud, exp, nbf, iat, jti) are defined in RFC 7519. Any additional fields — role, email, tenant_id, custom scopes — are private claims defined by the issuer.

Signature

The signature is the cryptographic binding that ties the header and payload together. For HS256, it is computed as:

HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)

For asymmetric algorithms like RS256 or ES256, the private key signs the same header.payload string, and anyone with the corresponding public key can verify it. Because the hash generator (HMAC) or private key is never exposed, a jwt decoder can read the claims but cannot confirm authenticity — that is the job of your server-side JWT library.

Common JWT claims reference

RFC 7519 defines seven registered claim names. The table below lists each one with its security implications — useful when reviewing a token for the first time or building a jwt authentication flow.

Claim	Full name	Type	What to check
`iss`	Issuer	String / URI	Must exactly match your expected issuer URL. Mismatch means a token from a different service.
`sub`	Subject	String	The principal (usually user ID). Verify it maps to a real account in your system.
`aud`	Audience	String or array	Must include your API identifier. Accepting tokens meant for another service is an aud confusion attack.
`exp`	Expiration	NumericDate	Always enforce. Compare to current Unix time. A missing or far-future exp is a red flag.
`nbf`	Not Before	NumericDate	Token is invalid before this time. Allow up to 60 seconds of clock skew.
`iat`	Issued At	NumericDate	Useful for detecting suspiciously old tokens even if exp hasn't passed.
`jti`	JWT ID	String	Unique identifier per token. Store consumed JTIs to implement one-time-use or revocation.

Decoding is not verifying

A JWT has three parts separated by dots: a header, a payload, and a signature. The header and payload are just base64url-encoded JSON — anyone can decode them. The signature is a cryptographic check computed over the header+payload using a secret (HMAC) or private key (RSA/ECDSA).

This tool decodes. It does not verify. Verification requires the issuer's signing key. You should never paste that key into a website — use your language's JWT library (jsonwebtoken in Node, PyJWT in Python, jose in most stacks) on your server, where the key already lives.

A decoded JWT proves nothing about authenticity. Never trust a decoded token's claims without verifying the signature first. Pen-testers and attackers can create fake tokens that decode perfectly fine. For a deeper treatment, see our guide on decode vs verify and the companion JWT security checklist.

When to use a JWT decoder

A jwt decoder is a daily tool for backend and frontend developers working with token-based authentication. The most common scenarios:

Debugging expired tokens. A 401 response during development often means an expired JWT. Pasting the token here immediately shows the exp timestamp and whether the token window has closed — faster than grepping logs.
Inspecting claims during development. When building jwt authentication for the first time, you need to confirm the issuer is putting the right claims into the token. Decode the token returned by your auth server before writing a single line of claim-reading code.
Reading third-party tokens. OAuth 2.0 access tokens, OIDC ID tokens, and vendor-issued JWTs (AWS Cognito, Auth0, Firebase) all follow the same three-part structure. Decode them to understand what claims are available before writing integration code.
Troubleshooting 401 errors. When your API returns 401 and the logs say "invalid token," the problem is usually one of four things: wrong audience, expired exp, wrong issuer, or algorithm mismatch. A decoded jwt lets you rule out three of those four in under ten seconds.

Header claims you should recognize

alg — signing algorithm. HS256, RS256, ES256 are common. none is a legendary security disaster — never accept.
typ — token type. Usually JWT. Newer specs use at+jwt for OAuth 2.0 access tokens.
kid — key ID. When an issuer rotates keys, kid tells your verifier which key to use from their JWKS.
jku / jwk — embedded key URL / key. Security-sensitive; never trust without strict allowlisting.

JWT security pitfalls

The "alg: none" attack

If your JWT library accepts alg: none, an attacker can create tokens with no signature that pass verification. Always validate the alg against an allowlist — e.g., only RS256.

HS256 vs RS256 key confusion

If your verifier accepts both symmetric (HS*) and asymmetric (RS*, ES*) algorithms with the same key lookup, an attacker can sign a token with your public key using HS256 and your verifier will accept it. Lock the algorithm per issuer.

Missing exp check

Some JWT libraries verify the signature but don't check exp unless you ask. Always verify expiration. Old tokens are replay fodder.

Unvalidated jku / x5u

Headers that include a URL pointing to the signing key let the attacker choose the key. If your verifier fetches jku without strict domain pinning, you're giving away signature verification.

Privacy

Every byte of processing happens in your browser. Open DevTools → Network and paste a token: no request is sent. You can disconnect from the internet and the tool keeps working. The source is on GitHub for inspection.

Even so — if a token contains production credentials, PII, or API keys, be conscious that pasting into any browser tab leaves traces (browser history, clipboard managers, auto-save). For genuinely sensitive tokens, decode locally via CLI instead.

Frequently asked questions

Can I decode a JWT without the secret?

Yes — for the header and payload. Both segments are base64url-encoded JSON and require no key whatsoever to read. Any tool, including this one, can decode them. The signature segment, however, cannot be verified without the secret (for HS256) or the issuer's public key (for RS256/ES256). Decoding only tells you what claims are in the token; verification tells you whether to trust them.

Is it safe to paste JWTs into an online decoder?

For non-production tokens, yes. This tool is 100% client-side — your token is never sent to any server. You can confirm this by opening your browser's DevTools Network tab and pasting a token: zero outbound requests are made. For production tokens carrying real user sessions, PII, or elevated privileges, the safer practice is to decode locally using a CLI tool or a quick script with your language's JWT library.

What's the difference between decoding and verifying a JWT?

Decoding means base64url-decoding the header and payload segments to read the JSON claims inside. It requires no key and proves nothing about authenticity — anyone can decode any JWT. Verifying means cryptographically confirming that the signature was produced by the legitimate issuer's key and that the token hasn't expired, been tampered with, or been issued to a different audience. Verification requires the issuer's secret (HS256) or public key (RS256/ES256) and must happen server-side. For a full breakdown, read our article on decode vs verify.

Can this tool verify my JWT?

Intentionally no. Verifying HS256 requires the shared secret; RS256/ES256 require the public key. Pasting secrets into web forms is a bad habit even when the site is client-side — verify server-side with your JWT library instead.

What's the difference between JWT, JWS, and JWE?

JWT is the claim format. JWS is the signed envelope (what you usually see — three dot-separated parts). JWE is the encrypted envelope (five parts, rare). This tool handles JWS. JWE would be opaque to any decoder that lacks the decryption key.

Why is my token's signature 512+ characters?

Longer signatures indicate asymmetric algorithms (RS256 signatures are ~344 chars, RS512 ~683 chars). HS256 signatures are 43 chars (Base64URL of a 32-byte HMAC). Length is a quick way to eyeball the algo.

The decoder shows "not yet active." Is my token broken?

Your token has an nbf (not-before) claim set to a future time. Either the issuer set it wrong, or your clock is behind the issuer's. Check Date.now() vs nbf * 1000. Clock-skew tolerance is typically 30–60 seconds in real verifiers.

My token shows "EXPIRED" but my API still accepts it. Why?

Your API isn't checking exp, your API's clock is wrong, or your API is caching a prior successful verification. All three are bugs — fix the server, not the token.

Related tools

Base64 Decoder — JWT header and payload are base64url-encoded; use this tool to decode individual segments manually.
hash generator — JWT signatures rely on HMAC-SHA256 (HS256) or stronger; explore how HMAC hashing works here.
JSON Formatter — Format, validate, and beautify JSON online. 100% client-side — your data never leaves your browser.
URL Encoder / Decoder — Percent-encode and decode URLs per RFC 3986.

Pillar

Part of Encoding & Crypto — Base64, URL, JWT, hashes, UUID, QR, password.

Written and maintained by Mian Ali Khalid. Last updated 2026-05-12.

JWT Decoder — Decode JSON Web Tokens Instantly