Decode JSON Web Tokens instantly. View header, payload, and claims without signature verification.

Security Notice: This tool decodes the token locally in your browser; it does NOT verify the signature. Never paste production secrets, private tokens, or tokens you don’t control.
0 characters

Paste a JWT token above to decode its header and payload

A JSON Web Token (JWT) is an open standard for securely transmitting information as a self-contained JSON object. Each JWT is composed of three Base64URL-encoded parts separated by dots: header.payload.signature. The header specifies the token type and hashing algorithm; the payload contains claims (user data, roles, expiration, etc.); and the signature proves the token wasn’t tampered with by the issuer. Unlike encryption, JWTs are signed, not encrypted—the payload is readable but cryptographically verified. This makes them ideal for stateless authentication, API authorization, and information exchange between parties.

What Each Part Contains

  • Header: A JSON object containing the token type (“JWT”) and the algorithm used to sign it (e.g., HS256, RS256, ES256).
  • Payload: A JSON object containing claims—statements about the user or entity. Standard claims include sub (subject/user ID), iss (issuer), exp (expiration time), iat (issued at), nbf (not before), and custom claims defined by the application.
  • Signature: A cryptographic hash of the encoded header and payload, signed with a secret key (for symmetric algorithms like HS256) or private key (for asymmetric algorithms like RS256). This ensures the token wasn’t modified.

Common JWT Claims

  • sub — Subject: Unique identifier for the user or entity (e.g., user ID).
  • iss — Issuer: The server or service that created the token.
  • exp — Expiration Time: Unix timestamp (seconds since epoch) when the token expires.
  • iat — Issued At: Unix timestamp when the token was created.
  • nbf — Not Before: Unix timestamp before which the token must not be accepted.
  • aud — Audience: The intended recipient(s) of the token.
  • Custom claims — Application-defined data (e.g., roles, permissions, user email).

Decode vs. Verify

Decoding means extracting and reading the data from the header and payload. Verifying means checking the signature to ensure the token was issued by a trusted authority and has not been tampered with. This decoder tool performs decoding only —it does not verify the signature. Never trust a JWT’s contents without signature verification on the server side. An attacker could create a fake JWT with false claims; signature verification is the only way to confirm legitimacy.

Use Cases

  • API Authentication: Include the JWT in request headers to authenticate API calls without session cookies.
  • Single Sign-On (SSO): Issue a JWT after login; use it across multiple applications without re-entering credentials.
  • Authorization: Store roles and permissions in the payload to control what users can access.
  • Information Exchange: Safely transmit claims about a user or entity between parties.
  • Stateless Sessions: No server-side session storage needed—the token itself contains all user data.
Security Warning:

This tool decodes JWTs locally in your browser and does not verify the signature. Decoding alone cannot prove a token is legitimate—only the server that issued it can verify its authenticity using the signing key. Never paste production JWTs or tokens containing sensitive information that you don’t fully control. Always verify JWTs on the server before trusting their claims for authentication or authorization decisions.

Frequently Asked Questions

Can JWTs be used without HTTPS?

Technically JWTs can be transmitted over HTTP, but it is never recommended. Always use HTTPS to prevent man-in-the-middle attacks. An attacker on an unencrypted connection could intercept and steal the JWT, then impersonate the user.

Can I decrypt a JWT to see the original password?

No. JWTs are signed, not encrypted. The payload is Base64URL-encoded and readable to anyone with the token, but it is not encrypted. If you need to hide data in a JWT, use encryption (like JWE—JSON Web Encryption) in addition to signing. Passwords should never be stored or transmitted in JWTs.

What happens if a JWT’s expiration time has passed?

The server should reject the token and require a new one (typically issued by a refresh token flow). An expired JWT is still readable to anyone who decodes it, but a properly implemented server will refuse to accept it for authentication or authorization. Always verify the exp claim on the server side.

For more information on JWTs, see the official specification: RFC 7519