What is a JWT and how does JWT decoding work?

A JSON Web Token (JWT) is a compact, URL-safe token defined in RFC 7519 consisting of three Base64url-encoded segments separated by dots: a header (declaring the algorithm), a payload (containing claims), and a cryptographic signature. JWT decoding is the process of Base64url-decoding the header and payload to reveal the original JSON. Anyone with the token can decode it — no key required. Decoding is different from verification, which requires the signing key to confirm authenticity.

Is it safe to decode a JWT online?

It depends on the tool. Many online JWT decoders send your token to a remote server, which is a serious security risk since a JWT may contain user identities, session scopes, and role assignments. JWT Decode processes everything locally in your browser — your token is decoded by your own device and is never transmitted to any server. You can verify this by opening your browser's DevTools Network tab and confirming there are zero outbound requests when you paste a token. You can also disconnect from the internet and the tool still works perfectly.

What is the difference between decoding and verifying a JWT?

Decoding a JWT simply Base64url-decodes the header and payload to reveal the original JSON — anyone with the token can do this without any key. Verification is the separate cryptographic step that proves the token is authentic and has not been modified. To verify, you need either the HMAC shared secret (for HS256/384/512) or the issuer's public key (for RS256/384/512 or ES256/384/512). Never make authorization decisions based on decoded claims alone — always verify signatures server-side.

Can I decode a JWT without the secret key?

Yes — the header and payload of a JWT are simply Base64url-encoded JSON, not encrypted. Any JWT can be fully decoded without any key whatsoever. The secret or key is only needed to verify the signature (authenticity), not to read the payload (confidentiality). This is a critical security property: JWT payloads are readable by anyone who has the token. Never store passwords, private keys, or sensitive secrets inside JWT claims.

No — a standard JWT (JWS) is signed, not encrypted. The header and payload are Base64url-encoded, which is trivially reversible by anyone. The signature only proves the token was created by a specific key holder and has not been tampered with — it does not hide the payload contents. If you need confidentiality, use JSON Web Encryption (JWE), which does encrypt the payload. Never put passwords, credit card numbers, or private secrets in a standard JWT payload.

What are the standard JWT claims?

RFC 7519 defines seven registered claim names: iss (Issuer — who created the token), sub (Subject — typically a user ID), aud (Audience — intended recipient), exp (Expiration Time — Unix timestamp after which the token is invalid), nbf (Not Before — Unix timestamp before which the token must not be accepted), iat (Issued At — when the token was created), and jti (JWT ID — unique identifier to prevent replay attacks). Applications commonly add private claims such as name, email, roles, or org for application-specific data.

What JWT signing algorithms does this decoder support?

JWT Decode supports decoding tokens signed with any algorithm. For signature verification it supports: HMAC algorithms HS256, HS384, and HS512 (shared secret); RSA algorithms RS256, RS384, and RS512 (PEM public key); ECDSA algorithms ES256, ES384, and ES512 (EC PEM public key); and RSA-PSS algorithms PS256, PS384, and PS512. All cryptographic operations run locally via the browser's Web Crypto API — no keys or tokens are sent to any external service.

Why is my JWT expired and how do I fix it?

A JWT is expired when the current time is past the exp (expiration) claim, a Unix timestamp in seconds. To fix: confirm your server clock is correct (clock skew is a common cause); check that your JWT library sets exp correctly when issuing tokens; ensure your client requests a fresh token rather than caching old ones; and verify your refresh-token flow is working. In production, never extend expiry as a workaround — fix the root cause in your token issuance or refresh logic.

How is JWT Decode different from jwt.io?

The core difference is privacy by design. JWT Decode never transmits your token anywhere — there is no backend, no analytics, and no external requests involving your token. All decoding and signature verification uses JavaScript running locally on your device via the browser's built-in Web Crypto API. Additional features include per-claim descriptions, relative and absolute timestamp display, algorithm-specific verification UI, raw Base64url inspection, a JWT anatomy guide, and full dark and light mode support.

How do I verify a JWT signature online?

On jwtdecode.app, paste your JWT into the input field, then click the Verify tab. For HMAC tokens (HS256/384/512), enter the shared secret string. For RSA tokens (RS256/384/512) or RSA-PSS (PS256/384/512), paste the RSA public key in PEM format. For ECDSA tokens (ES256/384/512), paste the EC public key in PEM format. The algorithm is detected automatically from the JWT header. All verification runs locally using the browser's Web Crypto API — your key is never sent anywhere.

JWT Decoder, Inspector & Signature Verifier

A JSON Web Token (JWT) is a compact, self-contained token format — defined in RFC 7519 — used to securely represent identity and session claims between services. When you log in to a modern web application, API, or OAuth 2.0 service, the access token you receive is almost always a JWT.

Paste any JWT below to instantly decode the header and payload, inspect all standard and custom claims with human-readable timestamps, and optionally verify the signature using HS256/RS256/ES256 and all standard variants.

This is a private JWT decoder that runs entirely in your browser via the Web Crypto API — you can decode a JWT without sending it to any server. The tool is a fully local JWT decoder: no upload, no account, no telemetry on token contents. You can verify there are zero outbound network requests carrying your token in DevTools → Network.

Developers debugging auth flowsQA engineers inspecting test tokensSecurity engineers auditing claimsAPI integrators reading token content

Instant decode

No button click needed

Local-only

Token stays in browser

Verify signatures

HS256, RS256, ES256+

Timestamp display

Human-readable exp/iat

JWT processing is 100% local·No tokens transmitted · Ads served by Google AdSense

JWT Input

Paste any JWT token to decode it instantly

View the decoded header, payload, and all claims — including expiry status, issuer, subject, audience, and custom claims.

All JWT decoding runs locally in your browser. Your token is never sent to any server, stored, or logged. Disconnect from the internet and this tool still works.

HS256 / RS256 / ES256 verificationexp · nbf · iat timestampsClaims inspectorRaw Base64url viewJWT anatomy guide

How to Use This JWT Decoder

A step-by-step guide to decoding, inspecting, and verifying JSON Web Tokens with this tool.

Paste your JWT token

Copy any JWT from your application, API response, browser DevTools, or HTTP header and paste it into the input field above. The decoder processes the token in real time as you type — no button click required. You can also click Load sample to see a complete token with all standard claims pre-populated.

A valid JWT contains exactly three Base64url-encoded segments separated by dots (header.payload.signature). The segment counter shows how many parts were detected. If it reads less than 3/3, the token may be truncated or malformed.

Read the Decoded tab

The Decoded tab displays syntax-highlighted JSON for both the header and payload. The header shows the signing algorithm (alg) and token type (typ). Common algorithms include HS256 (HMAC-SHA256, shared secret), RS256 (RSA-SHA256, asymmetric key pair), and ES256 (ECDSA-SHA256).

An amber warning reminds you that decoding is not verification: anyone can decode a JWT without a key. The payload is Base64url-encoded, not encrypted, so its contents are fully readable by anyone holding the token.

Inspect claims in the Claims tab

The Claims tab gives you a structured view of every claim. Standard registered claims receive labelled cards with explanations:

expExpiration — shows Active or Expired with a status badge
nbfNot Before — shows Not Yet Valid if still in the future
iatIssued At — formatted as a human-readable date and relative time
issIssuer — the auth server that created the token
subSubject — typically a user ID or service account
audAudience — the intended recipient of the token
jtiJWT ID — unique identifier to prevent replay attacks

Custom claims defined by your application appear in a separate section below.

Verify the signature (optional)

Go to the Verify tab and enter the appropriate key to cryptographically confirm whether the token's signature is valid:

·HMAC tokens (HS256/384/512): paste or type the shared secret string
·RSA tokens (RS256/384/512, PS256/384/512): paste the public key in PEM format
·ECDSA tokens (ES256/384/512): paste the EC public key in PEM format

All cryptographic operations use the browser's built-in Web Crypto API. Your key is never transmitted. A green result means the signature is valid; red means the key is wrong, the algorithm mismatched, or the token was tampered with.

Troubleshoot common issues

▸"Expired" badge — The exp claim is in the past. Check your server clock and token issuance logic. Never extend expiry to work around bugs — fix the root cause.
▸"Invalid signature" — Caused by: wrong secret or key, wrong key format (raw vs. base64), token modified after signing, or alg mismatch. Double-check the key and algorithm.
▸"Malformed JWT" — The token must have exactly three dot-separated segments. Whitespace, line breaks, or extra characters will cause parse failures. Copy the token fresh from the source.
▸Missing exp claim — The token shows "No Expiry." Technically valid, but poor security practice — tokens without an expiration remain valid indefinitely unless actively revoked.

For a comprehensive reference, see the Common JWT Errors and Fixes guide.

JWT Structure Explained

A JSON Web Token has three Base64url-encoded segments separated by dots. Understanding each part helps you decode and verify tokens correctly — and avoid common security mistakes.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImlhdCI6MTcxNjQ3NzM2MSwiZXhwIjoxNzE2NDgwOTYxfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HeaderPayloadSignature

Header

The header is a JSON object that declares the token type and the signing algorithm. It is Base64url-encoded — not encrypted — so anyone can read it without a key.

{
  "alg": "HS256",   // signing algorithm
  "typ": "JWT",     // token type
  "kid": "key-01"  // key ID (optional hint for verification)
}

The alg field controls how the signature is computed and must be validated by the receiver. Never accept a token where alg has been substituted with "none" — this is a known algorithm confusion attack.

Payload

The payload contains the token's claims — key-value statements about the subject and session. It is Base64url-encoded but NOT encrypted. Anyone holding the token can read every claim without a key. Never store passwords, secrets, or sensitive PII in a JWT payload.

{
  "sub": "user_123",              // Subject (user ID)
  "iss": "https://auth.acme.com", // Issuer
  "aud": "https://api.acme.com",  // Audience
  "exp": 1716480961,              // Expiry (Unix timestamp)
  "iat": 1716477361,              // Issued At
  "name": "Jane Developer",       // Custom claim
  "roles": ["editor", "viewer"]   // Custom claim
}

Signature

The signature is computed over base64url(header) + "." + base64url(payload) using the signing key. It makes the token tamper-evident: if a single byte of the header or payload changes, the signature no longer matches. However, the signature only proves authenticity when you actually verify it — decoding alone tells you nothing about whether the token is authentic.

// For HS256:
HMACSHA256(
  base64url(header) + "." + base64url(payload),
  shared_secret
)

// For RS256:
RSA_SHA256_Sign(
  base64url(header) + "." + base64url(payload),
  private_key
)

What is Base64url encoding?

Base64url is a variant of standard Base64 that replaces + with - and / with _, and omits padding characters (=). This makes JWTs safe to use in URLs, HTTP headers, and cookies without additional encoding. Crucially, Base64url is a reversible encoding — not encryption. Any Base64url string can be decoded by anyone, with no key required. The JSON payload inside a JWT is therefore readable by anyone who has the token.

JWT Security Notes

Essential security considerations every developer working with JWTs should understand.

Always verify signatures server-side

Decoding a JWT reveals its claims but proves nothing about authenticity. Server-side signature verification — using a trusted JWT library with your issuer's public key or shared secret — is the only way to confirm a token is genuine and unmodified. Client-side verification (as this tool provides) is for debugging and inspection only.

Decoded payloads can be tampered with

If your application reads JWT claims without verifying the signature, an attacker can modify the payload and re-encode it. A common example: changing "role": "user" to "role": "admin". The signature will then be invalid — but only if you check it. Applications that skip verification are vulnerable to privilege escalation.

Validate exp, nbf, iss, and aud explicitly

Signature verification proves the token was signed with a known key. It does not automatically enforce claim constraints. Your server must still explicitly: reject tokens where exp is in the past, reject tokens where nbf is in the future, verify iss matches the expected issuer URL, and verify aud matches your service identifier. Many real-world vulnerabilities come from skipping these checks.

Never store sensitive data in JWT payloads

The JWT payload is encoded, not encrypted — it is readable by anyone who has the token, including users, proxies, and logging systems. Never include passwords, API secrets, private keys, credit card numbers, social security numbers, or unredacted PII in JWT claims. For sensitive data that must travel in a token, use JSON Web Encryption (JWE) instead.

Protect your signing keys

For HS256, your shared secret must be long (at least 32 bytes of high-entropy random data), kept out of source control, and rotated immediately if compromised. For RS256/ES256, never expose your private key in client-side code. Publish your public keys via a JWKS endpoint and implement key rotation with overlap periods so existing tokens remain verifiable during rotation.

Use this tool safely with production tokens

Although this tool processes tokens entirely in your browser (nothing is transmitted), good security hygiene still applies: avoid pasting live production tokens from critical systems into browser-based tools when possible. Use staging tokens or development tokens for debugging. If you must inspect a production token, disconnect from the network first to confirm no requests are made, then clear the input field when done.

For a complete security reference, see the JWT Security Best Practices guide.

Frequently Asked Questions

Common questions about JWT decoding, verification, and security.

JWT decode is the process of Base64url-decoding a JSON Web Token to reveal its header and payload. A JSON Web Token (JWT) is a compact, URL-safe token defined in RFC 7519 that consists of three dot-separated segments: a header declaring the algorithm, a payload containing claims (key-value data), and a cryptographic signature. Developers decode JWTs to inspect the claims a token carries — such as user ID, roles, expiry time, and issuer — without needing access to the signing key. Common use cases include debugging authentication issues, inspecting third-party tokens, validating claim values during development, and understanding what data a token exposes.