JWT Decoder

Decode any JSON Web Token instantly — view the header algorithm, all payload claims, and expiry status. Your token never leaves your browser.

JWT Token
Paste a JWT token above…

What is a JWT (JSON Web Token)?

A JSON Web Token (JWT) is a compact, URL-safe format for securely transmitting claims between two parties — typically between a client application and a server. A JWT consists of three Base64URL-encoded sections separated by dots: the Header, the Payload, and the Signature. JWTs are the most common token format used in modern API authentication, OAuth 2.0 flows, and single sign-on (SSO) systems.

When you log in to an application, the server creates a JWT, signs it with a secret key, and returns it to your client. Your client includes this token in the Authorization: Bearer <token> header of subsequent requests. The server verifies the signature and reads the claims without needing to query a database on every request.

JWT structure: Header.Payload.Signature

A JWT looks like: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTYiLCJuYW1lIjoiSmFuZSJ9.abc123

  • Header — Base64URL-encoded JSON describing the token type (JWT) and the signing algorithm (HS256, RS256, etc.).
  • Payload — Base64URL-encoded JSON containing the claims — data assertions about the user and the token itself.
  • Signature — the result of signing the encoded header and payload with a secret key or private key. The signature verifies the token has not been tampered with.

Standard JWT claims explained

  • sub — Subject: the unique identifier of the user or entity the token represents (e.g. a user ID)
  • iss — Issuer: identifies who created the token, typically your auth server URL
  • aud — Audience: identifies who the token is intended for; servers should reject tokens with an incorrect audience
  • exp — Expiry: Unix timestamp (seconds since epoch) after which the token is invalid; always check this
  • iat — Issued At: Unix timestamp when the token was created; useful for detecting tokens that are too old
  • nbf — Not Before: Unix timestamp before which the token must not be accepted; rarely used
  • jti — JWT ID: a unique identifier for this specific token; used to prevent replay attacks by maintaining a blocklist of used JTIs

Decoding vs verifying a JWT

There is an important distinction between decoding and verifying a JWT. Decoding simply Base64URL-decodes the header and payload to reveal the claims — anyone can do this without the secret key. Verification uses the signature and the secret (or public) key to confirm that the token was issued by a trusted party and has not been modified. This tool only decodes — it does not verify the signature. Never trust the claims in a JWT without first verifying its signature in your application code.

Is it safe to paste my JWT here?

This tool runs entirely in your browser using JavaScript — your token is never sent to any server. However, be cautious: JWT payloads are not encrypted, only Base64URL-encoded, so the claims are readable by anyone who has the token. Avoid pasting long-lived production tokens (e.g. refresh tokens) into any online tool. Short-lived access tokens (15–60 minute expiry) pose lower risk. When in doubt, use an expired or sample token for testing purposes.

Frequently asked questions

Yes. The header and payload are only Base64URL-encoded, not encrypted. Anyone who has the token can decode and read the claims. The secret key is only needed to verify the signature — to confirm the token was not tampered with. This tool decodes without verification.

The exp claim in the payload is a Unix timestamp (seconds since January 1, 1970 UTC). This tool compares it against the current time in your browser. If the current time is past the exp timestamp, the token is expired. Check whether the token was issued with the correct expiry duration or whether you need to obtain a new token.

HS256 (HMAC-SHA256) uses a single shared secret key for both signing and verification — both the issuer and verifier use the same key. RS256 (RSA-SHA256) uses a private key for signing and a public key for verification, allowing anyone to verify tokens without access to the private key. RS256 is preferred for public APIs and federated identity scenarios.

Standard JWTs (JWS — JSON Web Signature) are signed but not encrypted. The payload is visible to anyone with the token. If you need to hide the payload content, use JWE (JSON Web Encryption), which encrypts the payload. Most applications use signed JWTs and rely on HTTPS for transport security rather than payload encryption.

No. All decoding happens in your browser using JavaScript's atob() function. Your token is never transmitted to MockServer or any other server.
Related tools: Base64 Encoder JSON Formatter JSON Validator URL Encoder All Tools