Simple Interest Calculator Base64 Encoder / Decoder Credit Score Calculator Twitter/X Revenue Calculator CGPA, GPA & Percentage Calculator AI Learning Trainer Timezone Compare QR Code Generator Word & Character Counter Pants Size Calculator Color Converter Unix Timestamp Converter Unit Converter UUID Generator TFSA Calculator Simple Interest Calculator Base64 Encoder / Decoder Credit Score Calculator Twitter/X Revenue Calculator CGPA, GPA & Percentage Calculator AI Learning Trainer Timezone Compare QR Code Generator Word & Character Counter Pants Size Calculator Color Converter Unix Timestamp Converter Unit Converter UUID Generator TFSA Calculator

JWT Decoder

Decode and inspect JSON Web Tokens — view header, payload, claims, and expiration status

⚠️ Decoder Only — Not a Verifier

This tool decodes the JWT payload (which is just Base64-encoded JSON) but cannot verify the signature. Signature verification requires the server's secret key or public key, which is never shared publicly. Never trust a JWT's claims without server-side verification.

What Is a JSON Web Token (JWT)?

A JSON Web Token (JWT), pronounced "jot," is a compact, URL-safe token format used to securely transmit claims between two parties. Defined in RFC 7519, JWTs are widely used for authentication and authorization in modern web applications and APIs. A JWT consists of three parts separated by dots: a Header (specifying the algorithm and token type), a Payload (containing the claims — statements about the user and metadata), and a Signature (used to verify the token hasn't been tampered with). Each part is Base64url-encoded, making the entire token safe for use in URLs, cookies, and HTTP headers.

How JWTs Work in Authentication

In a typical authentication flow, a user logs in with their credentials, and the server creates a JWT containing the user's identity and permissions. This token is returned to the client (browser or mobile app) and stored — usually in localStorage, sessionStorage, or an HTTP-only cookie. For subsequent API requests, the client sends the JWT in the Authorization: Bearer <token> header. The server verifies the signature using its secret key (for HMAC algorithms like HS256) or public key (for RSA algorithms like RS256), then extracts the user's identity from the payload without needing to query a database. This stateless approach is what makes JWTs ideal for distributed systems and microservices.

Understanding JWT Claims

The JWT payload contains claims — key-value pairs that carry information about the user and the token itself. Registered claims are standardized names defined in the JWT specification: iss (issuer — who created the token), sub (subject — the user the token represents), aud (audience — who the token is intended for), exp (expiration time — when the token becomes invalid), iat (issued at — when the token was created), and nbf (not before — the earliest time the token is valid). Custom claims can contain any application-specific data, such as user roles, permissions, or preferences.

JWT Security Considerations

  • JWTs are NOT encrypted by default: The payload is merely Base64-encoded, meaning anyone can decode and read it. Never put sensitive data (passwords, credit card numbers) in a JWT payload.
  • Signature verification is essential: The signature prevents tampering — if anyone modifies the payload, the signature becomes invalid. Always verify signatures on the server.
  • Set short expiration times: JWTs cannot be individually revoked (unlike session IDs stored in a database). Use short exp values (15 minutes to a few hours) and implement refresh token rotation.
  • Use HTTPS: JWTs transmitted over HTTP can be intercepted. Always use HTTPS/TLS to encrypt the transport layer.
  • Beware of the "none" algorithm: Some JWT libraries incorrectly accept tokens with "alg": "none", bypassing signature verification entirely. Always validate the algorithm server-side.