JWT Decoder

Decode a JWT's header and payload instantly, entirely in your browser.

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1716239022,
  "iat_readable": "2024-05-20T21:03:42.000Z"
}

Signature

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

What Is the JWT Decoder?

A JSON Web Token (JWT) is a compact, three-part string used to represent claims between two parties — commonly for authentication. This tool decodes the header and payload of any JWT you paste in, entirely in your browser.

How Is the JWT Decoder Calculated?

A JWT is three base64url-encoded segments joined by dots: a header (describing the signing algorithm and token type), a payload (the actual claims, like user ID or expiry), and a signature (used by the issuing server to verify the token hasn't been tampered with). This tool decodes the header and payload — it does not and cannot verify the signature, since that requires the secret or private key used to sign it.

JWT Decoder Example

A token like eyJhbGc...eyJzdWI...SflKxw decodes into a header showing {"alg":"HS256","typ":"JWT"} and a payload showing the claims it carries, such as a subject ID and issued-at time.

How to Use the JWT Decoder

Step 1

Paste a JWT into the input box.

Step 2

View the decoded header and payload as formatted JSON.

Step 3

Timestamp claims (exp, iat, nbf) are also shown as readable dates alongside their raw Unix values.

Benefits

  • Instantly readable header and payload without writing any code.
  • Automatically converts standard timestamp claims into human-readable dates.
  • Decodes entirely in your browser — the token never leaves your machine.

Common JWT Decoder Scenarios

Scenario 1

Debugging why an API call with a JWT is failing, by checking its actual claims.

Scenario 2

Checking when a token expires without decoding it by hand.

Scenario 3

Understanding what data a third-party token actually contains before trusting it.

Understanding Your Result

The header tells you how the token was signed. The payload contains the actual claims — data the token is asserting, such as who it belongs to and when it expires. The signature is shown as-is; this tool doesn't verify it, since that requires the issuer's secret or public key, which this tool never asks for.

Tips

  • exp, iat, and nbf claims are Unix timestamps (seconds since 1970) — this tool converts them to readable dates automatically.
  • A decoded payload doesn't mean the token is valid — validity depends on signature verification and expiry, not just successful decoding.
  • Never paste a real production token from a live session into any third-party tool, including this one, if you're unsure how it handles the input.

Common Mistakes

  • Assuming a successfully decoded token is a verified, trustworthy token — decoding and verifying are different things.
  • Pasting only part of a token (missing a segment), which will fail to decode.
  • Confusing the JWT's own expiry claim with your application's session expiry, which may be tracked separately.

Frequently Asked Questions

Is my token sent anywhere?

No — decoding happens entirely in your browser using built-in JavaScript, and the token is never sent to a server.

Does this tool verify the token's signature?

No — verifying a signature requires the secret or public key used to sign the token, which this tool never asks for or has access to. It only decodes the header and payload.

Why can I read the payload without a secret key?

JWT payloads are only base64url-encoded, not encrypted, by default — anyone can decode them. The signature is what prevents tampering, not secrecy of the contents.

Should I put sensitive data in a JWT payload?

No — since the payload is readable by anyone who has the token, avoid putting passwords, secrets, or sensitive personal data directly in JWT claims.

What does the 'alg' field in the header mean?

It specifies which algorithm was used to sign the token, such as HS256 (HMAC with SHA-256) or RS256 (RSA with SHA-256) — the verifying party needs to use the matching algorithm and key.

What is the difference between exp, iat, and nbf?

iat is when the token was issued, exp is when it expires, and nbf ('not before') is the earliest time the token becomes valid — all are standard optional claims defined by the JWT specification.

Why does my token fail to decode?

This usually means the token is incomplete, was truncated when copied, or isn't a JWT at all — a valid JWT always has exactly three dot-separated segments.

Can I use this to create or sign a new JWT?

No — this tool only decodes existing tokens; creating a properly signed token requires a server-side library with access to your secret or private key.

Is a JWT the same as an API key?

No — an API key is typically an opaque, unstructured string, while a JWT is a structured, self-describing token that carries its own claims and can be decoded and inspected, as this tool demonstrates.

Important Information

This tool decodes tokens locally in your browser for debugging purposes and does not verify signatures. Avoid pasting sensitive production tokens into any third-party tool.

Last updated: August 9, 2026