JWT Decoder & Encoder: Inspect JSON Web Tokens Instantly

Decode any JWT token instantly in your browser or generate your own with the built-in encoder. View the header, payload, all claims with human-readable descriptions, expiry status, and a live countdown - no login, no account, no data ever leaves your browser.

100% browser-based · No server · No login · Completely private

Last updated: April 2026

0 chars

100% Free & 100% Private

All processing happens entirely in your browser. We never upload your data to any server. No signup, no account, no hidden fees. Just free, secure tools.

Browser BasedNo Server LogsNo History Stored

What Is a JWT Token? (JSON Web Token Explained)

A JWT (JSON Web Token) is a compact, URL-safe token format defined in RFC 7519, used to securely transmit information between parties as a digitally signed JSON object. JWTs are the standard mechanism for stateless authentication in modern web applications - the server encodes user identity and permissions into the token and signs it, so subsequent requests can be verified without a database lookup.

A JWT consists of three Base64url-encoded sections separated by dots (.):

Header

Specifies the token type (JWT) and signing algorithm (alg), such as HS256 or RS256. Base64url-encoded JSON.

Payload

Contains claims: statements about the user (sub, email, roles) and token metadata (exp, iat, iss). The payload is encoded, not encrypted - anyone with the token string can read the claims. Never store passwords, secrets, or sensitive personal data in a JWT payload.

Signature

A cryptographic hash of the header and payload, signed with a secret or private key. Used to verify the token was not tampered with. The key is never included in the token itself.

JWTs are widely used in REST APIs, microservices, single-page applications (React, Angular, Vue), and mobile app backends. To encrypt the payload, use JWE (JSON Web Encryption) instead of the standard JWT (technically JWS - JSON Web Signature).

How to Decode a JWT Token Online (Step by Step)

  1. Copy your JWT token from your application, browser developer tools (Application > Cookies or Authorization headers), or API response
  2. Paste the full token string into the input field above - it must start with eyJ (Base64url-encoded opening of a JSON object)
  3. The decoded header and payload appear instantly. Review all claims, the signing algorithm, and the token type
  4. Check the Token Status banner to see if the token is valid, expired, or not yet active, along with a live countdown timer
  5. Review the Security Audit panel for warnings like the use of the none signature algorithm or missing expiry times
  6. Use the Claims Breakdown table to interpret standard claims (such as exp, sub, iss) alongside their official RFC definitions
  7. Expand the Verification Code Snippets section to copy ready-to-use backend validation code in JS, Python, Go, Java, or cURL

JWT Claims Reference: sub, iss, aud, exp, iat, nbf, jti

  • sub - Subject. The principal the token is about, usually a user ID. (RFC 7519 §4.1.2)
  • iss - Issuer. The entity that issued the token, e.g. your auth server URL. (RFC 7519 §4.1.1)
  • aud - Audience. The intended recipients of the token. (RFC 7519 §4.1.3)
  • exp - Expiration Time. Unix timestamp after which the token must not be accepted. (RFC 7519 §4.1.4)
  • iat - Issued At. Unix timestamp of when the token was issued. (RFC 7519 §4.1.6)
  • nbf - Not Before. Unix timestamp before which the token must not be accepted. (RFC 7519 §4.1.5)
  • jti - JWT ID. Unique identifier for this token - used to prevent replay attacks. (RFC 7519 §4.1.7)

JWT vs Session Tokens: When Should You Use Each?

JWT (Stateless)Session Token (Stateful)
Server storage neededNoYes (session store/DB)
Works across microservicesYesRequires shared session store
Token revocationHard (need blocklist)Easy (delete from store)
Token sizeLarger (encoded claims)Small (random ID only)
Best forAPIs, mobile apps, microservicesTraditional web apps
Security on compromiseToken valid until expCan invalidate immediately

Use JWT when: Building stateless REST APIs, microservice authentication, mobile backends, short-lived tokens (15 min–1 hr), or cross-domain authentication.

Use sessions when: Building traditional server-side web apps, when you need immediate revocation, long-lived user sessions, or high-security applications.

JWT Signing Algorithms Explained: HS256 vs RS256 vs ES256

AlgorithmTypeKey TypeUse Case
HS256HMAC-SHA256Shared secretSingle-server apps, internal services
RS256RSA-SHA256Public/private key pairMulti-service auth, clients verify without secret
ES256ECDSA P-256Elliptic curve key pairPerformance-sensitive systems, mobile
PS256RSA-PSS SHA256Public/private key pairHigh-security, FIPS compliance
noneNoneNone⚠️ Never use - critical security vulnerability

RS256 is recommended for most production systems because the public key can be distributed to any service that needs to verify tokens, without exposing the signing secret.

JWT Security Best Practices for Developers (2026)

  • Always verify the JWT signature on the server before trusting any claims
  • Set a reasonable expiration time - short-lived tokens (15 min–1 hr) reduce the impact of token theft
  • Never store sensitive data like passwords or private keys in the JWT payload (it is NOT encrypted)
  • Use HTTPS for all token transmission - never send tokens over unencrypted connections
  • Store tokens securely - use httpOnly cookies rather than localStorage to prevent XSS attacks
  • Implement token refresh mechanisms for long-lived sessions using short-lived access tokens + refresh tokens
  • Validate the iss and aud claims to prevent token substitution attacks
  • Never accept tokens with alg: none - this disables signature verification and is a known attack vector
  • Use a JWT blocklist or short expiry for immediate revocation when needed

How to Decode a JWT Token in Code

These examples decode the payload without signature verification - the same operation this browser tool performs.

JavaScript (Browser / Node.js)

// Decode without verification (read-only, same as this tool)
function decodeJWT(token) {
  const [header, payload] = token.split('.');
  const decode = str => JSON.parse(atob(str.replace(/-/g, '+').replace(/_/g, '/')));
  return { header: decode(header), payload: decode(payload) };
}

const { header, payload } = decodeJWT(yourToken);
console.log(payload.exp); // expiry timestamp

Python

import base64, json

def decode_jwt_payload(token):
    payload = token.split('.')[1]
    # Add padding
    payload += '=' * (4 - len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload))

claims = decode_jwt_payload(your_token)
print(claims['exp'])  # expiry timestamp

Go

import (
    "encoding/base64"
    "encoding/json"
    "strings"
)

func decodeJWTPayload(token string) (map[string]interface{}, error) {
    parts := strings.Split(token, ".")
    payload, _ := base64.RawURLEncoding.DecodeString(parts[1])
    var claims map[string]interface{}
    json.Unmarshal(payload, &claims)
    return claims, nil
}

JWT vs Session Tokens: When Should You Use JWTs?

JWTs are ideal for stateless authentication where the server does not need to store session information. Because all user data is encoded in the token itself, the server can verify identity without a database lookup. They are widely used in REST APIs, microservices, single-page applications, and mobile app backends. However, JWTs should not be used to store sensitive data in the payload since the payload is only Base64url-encoded, not encrypted.

Frequently Asked Questions

What is a JWT token?

A JWT (JSON Web Token) is a compact, URL-safe token format defined in RFC 7519, used to securely transmit information between parties as a digitally signed JSON object. It consists of three Base64url-encoded parts separated by dots: a header (algorithm and token type), a payload (claims about the user or session), and a signature for tamper verification. JWTs are widely used for stateless authentication in REST APIs, single-page applications, and microservices.

How do I decode a JWT token?

Paste your JWT token into the input field above - the decoder instantly shows the decoded header and payload, all claims with human-readable descriptions, and the token expiry status. No signup, account, or installation required.

Can I decode a JWT token without the secret key?

Yes. The header and payload of a JWT are only Base64url-encoded, not encrypted. Any tool can decode and read them without the secret key. The secret key is only needed to verify the signature - which confirms the token was not tampered with. Decoding (reading the content) and verifying (checking authenticity) are two separate operations.

Is it safe to paste my JWT token into an online decoder?

This tool is safe because all decoding happens entirely in your browser - no data is ever sent to a server. You can verify this in your browser's DevTools Network tab: no requests are made when you paste a token. As a general best practice, avoid pasting live production tokens into any online tool. Use tokens from development or staging environments for debugging.

How do I check if a JWT token is expired?

Paste your JWT token into this decoder. It reads the exp claim (a Unix timestamp) and compares it to the current time in your browser. A live countdown timer is shown for valid tokens, and an Expired banner is displayed for tokens past their expiry time. The iat (issued at) claim shows when the token was created.

What is the difference between JWT encode and JWT decode?

Encoding a JWT means taking a JSON header and payload, Base64url-encoding each part, and appending a cryptographic signature to form the final token string. Decoding reverses this - it splits the token at the dots, Base64url-decodes each part, and reads the JSON. Decoding does not verify the signature; verification is a separate step that requires the secret key.

What does the alg field mean in a JWT header?

The alg (algorithm) field in the JWT header specifies which cryptographic algorithm was used to sign the token. Common values are: HS256 (HMAC-SHA256, uses a shared secret key), RS256 (RSA-SHA256, uses a public/private key pair), and ES256 (ECDSA with P-256 curve). Security warning: never accept tokens where alg is set to 'none' - this disables signature verification and is a known attack vector.

Is the JWT payload encrypted?

No. The JWT payload is only Base64url-encoded, not encrypted. Anyone who has the token can decode and read the payload without a key. Never store sensitive information like passwords, private keys, or personal data in a JWT payload. If you need to encrypt the payload, use JWE (JSON Web Encryption) instead of the standard JWT (which is technically JWS - JSON Web Signature).

What does 'token not yet valid' mean in JWT?

This means the nbf (not before) claim in the token is set to a future Unix timestamp. The token has been issued but should be rejected by servers until that time arrives. This is used for scheduled access - for example, issuing a token in advance that only becomes active at a specific scheduled time.

What is the difference between iat and exp in JWT?

iat (issued at) is the Unix timestamp when the token was created. exp (expiration) is when it stops being valid. The difference (exp - iat) is the token's total lifetime. Both are shown as human-readable dates by this decoder.

Can JWTs be used without HTTPS?

Technically yes, but you must never do this in production. Without HTTPS, JWTs can be intercepted in transit, allowing attackers to impersonate users. Always transmit JWTs over TLS/HTTPS. Store them in httpOnly cookies rather than localStorage to prevent XSS theft.

What is the difference between JWT and JWE?

A standard JWT (technically JWS - JSON Web Signature) has a signed but readable payload. JWE (JSON Web Encryption) encrypts the payload so it cannot be read without the decryption key. Use JWE when the payload contains sensitive data that must not be visible to token holders.

What are JWT claims?

JWT claims are key-value pairs in the payload section of a JWT. Standard claims include sub (subject), iss (issuer), aud (audience), exp (expiration time), iat (issued at), and nbf (not before). Custom claims can be added for application-specific data like user roles, permissions, or IDs.