JWT Decoder

Paste a JSON Web Token to decode its header and payload. Signatures are never verified server-side — everything runs in your browser.

⚠️

Never paste production tokens or tokens containing sensitive data into any online tool. This tool runs entirely in your browser and sends no data to a server, but it is best practice to use test/sample tokens only.

About JWT Decoder

A JSON Web Token (JWT) consists of three Base64URL-encoded parts separated by dots: a header, a payload, and a signature. This tool decodes the header and payload so you can inspect the claims — including expiry time, issuer, and custom data — without needing your server or a library. Nothing is sent to a server; the entire decode runs in your browser.

JWT structure explained

  • Header — contains the token type (typ: "JWT") and the signing algorithm (e.g. alg: "HS256" or RS256).
  • Payload — contains claims. Standard claims include sub (subject), iss (issuer), exp (expiry timestamp), iat (issued-at), and aud (audience). Custom claims can hold user roles, IDs, and other app-specific data.
  • Signature — a cryptographic hash of the header and payload signed with a secret or private key. This tool does not verify signatures — do that server-side with your signing key.

When to use a JWT decoder

Decoding a JWT is useful when debugging authentication issues — for example, checking whether a token has expired (exp claim), what roles are encoded in it, or which environment issued it (iss claim). Remember: the payload is only Base64URL-encoded, not encrypted, so never put sensitive information like passwords inside a JWT.

About the JWT Decoder

A JSON Web Token (JWT) is a compact, URL-safe way of representing claims between two parties. JWTs are the most common way to carry user identity through a stateless web API: the server signs a token containing the user's ID and a few other claims, the client stores it (in memory, in localStorage, or in a cookie), and every subsequent API call includes the token in an Authorization header. JWTs are widely used in OAuth 2, OpenID Connect, and most "Login with…" flows.

A JWT is three Base64URL-encoded segments separated by dots: header.payload.signature. The header and payload are JSON. This tool splits a JWT and shows the decoded header and payload, including human-readable timestamps for the standard exp, iat, and nbf claims. Verification of the signature is not performed here — that requires the issuer's public key, which would have to be supplied or fetched.

What is inside a JWT

The header declares the signing algorithm (HS256, RS256, ES256 are the most common). The payload contains "claims": registered claims defined by the spec (iss, sub, aud, exp, iat, nbf, jti), and any number of custom claims the application chooses. The signature is computed over the header and payload with a secret (HMAC) or a private key (RSA, ECDSA), and prevents tampering: any change to header or payload invalidates the signature.

Important: decoding does not mean trusting

A decoded JWT is just data — anyone with the token can read its payload, because Base64URL is not encryption. Never put sensitive data (passwords, full credit card numbers) into a JWT payload. Trusting the payload requires verifying the signature against the issuer's key. This tool does not verify; it only decodes. Treat decoded payloads as untrusted until verified server-side.

How to use the JWT Decoder

  1. Paste the JWT

    Drop the full token (the long string with two dots) into the input box.

  2. Read the decoded header and payload

    Both are shown as formatted JSON. Standard timestamp claims (exp, iat, nbf) are also rendered in a human-readable form.

  3. Check expiry at a glance

    If the token is expired (exp in the past), the tool flags it clearly. If not yet valid (nbf in the future), that is flagged too.

Worked examples

Example 1

Input: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhbGljZSIsImV4cCI6MTcwMDAwMDAwMH0.signature

Result: Header: { "alg": "HS256" } / Payload: { "sub": "alice", "exp": 1700000000 }

A minimal example. In practice payloads carry many more claims.

Real-world use cases

  • Debugging "401 Unauthorized" errors by checking whether the token is expired.
  • Inspecting claims sent by an OAuth identity provider during integration testing.
  • Confirming that a custom claim you added on the server actually appears on the client.
  • Quickly checking whether two tokens carry the same user ID.
  • Teaching the JWT structure to a teammate without firing up a debugger.

Tips & common mistakes

  • A JWT is not encrypted. Anyone who can read the token can read the payload. Use HTTPS in transit and never include secrets in claims.
  • The alg header should not be trusted on the client side. Servers must enforce the expected algorithm — accepting alg=none has caused major security breaches.
  • Short expiry times (15 minutes to an hour) plus a refresh token is the modern recommended pattern. Long-lived JWTs are a frequent source of session-hijacking incidents.
  • A leaked JWT is valid until its exp. There is no easy revocation mechanism without server-side state. Treat tokens like passwords.

Frequently asked questions

Does the tool verify the signature?

No. Verification requires the issuer's secret or public key. Decoding alone tells you what the token claims, not whether it is genuine.

Is my token sent anywhere?

No. Decoding is purely client-side string manipulation. The token never leaves your browser.

Why does "exp" look like a huge number?

It is a Unix timestamp — seconds since 1970-01-01 UTC. The tool also displays it in human-readable form.

What is the difference between JWT, JWS, and JWE?

JWS is the signed form of a JWT (header.payload.signature). JWE is the encrypted form, where the payload itself is encrypted. Almost every JWT you encounter is actually a JWS. Encrypted JWEs are less common and have a different structure.

Related tools

→ Base64 Encoder→ Hash Generator→ JSON Formatter

Last updated: June 2026 · All processing happens locally in your browser.