PureDevTools

JWT Decoder

Decode JSON Web Tokens and inspect claims — all in your browser, nothing sent to any server

All processing happens in your browser. No data is sent to any server.

Paste a JWT above to instantly decode its header, payload, and signature. All decoding happens in your browser — your token never leaves this page.

What Is a JWT?

A JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between two parties as a compact, URL-safe string. JWTs are widely used for authentication and authorization in modern web applications — when you log into a service, the server typically issues a JWT that your client sends with every subsequent request to prove your identity.

A JWT consists of exactly three Base64URL-encoded parts, separated by dots (.):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← Header
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ   ← Payload
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c   ← Signature

The Three Parts of a JWT

The header is a JSON object that describes the token’s type and the signing algorithm used. It always contains at minimum the alg (algorithm) field and usually the typ (type) field:

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

Common algorithms include HS256 (HMAC-SHA256), RS256 (RSA-SHA256), and ES256 (ECDSA-P256-SHA256). The algorithm determines how the signature is created and verified.

Payload

The payload is a JSON object containing claims — statements about the subject of the token and any additional metadata. Claims are categorized as:

Signature

The signature verifies that the token has not been tampered with. For HMAC-based algorithms (HS256/HS384/HS512), the signature is computed as:

HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)

For RSA and ECDSA algorithms, a private key is used to sign and a public key is used to verify.

Standard JWT Claims (Registered Claims)

RFC 7519 defines seven standard registered claim names. This tool automatically detects and annotates them:

ClaimFull NameDescription
issIssuerIdentifies who issued the token (e.g., "https://auth.example.com")
subSubjectIdentifies the principal the token is about (e.g., a user ID)
audAudienceIdentifies the recipients the token is intended for
expExpiration TimeUnix timestamp after which the token must be rejected
nbfNot BeforeUnix timestamp before which the token must not be accepted
iatIssued AtUnix timestamp recording when the token was issued
jtiJWT IDUnique identifier for the token, used to prevent replay attacks

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 read their JSON contents. No secret is required. Anyone can decode a JWT — the payload is not encrypted, only encoded. This tool decodes instantly as you paste your token.

Verifying checks that the signature was created by the expected secret or private key, confirming the token’s authenticity and integrity. Without verification, you cannot trust the claims in the payload. This tool supports HMAC signature verification (HS256, HS384, HS512) using a secret you provide.

JWT Expiry and Timing Claims

The exp claim is the most important security claim. Servers must reject tokens whose exp timestamp is in the past. This tool automatically:

When working with JWTs, always validate expiry on the server side. Never trust client-side expiry checks alone.

Common JWT Use Cases

Authentication: After login, a server issues a JWT. The client stores it (typically in memory or a secure cookie) and sends it as a Bearer token in the Authorization header. The server validates the JWT on each request without querying a database.

Authorization: JWTs can contain role or permission claims ("role": "admin") that let servers make authorization decisions without a database lookup.

Information exchange: JWTs can securely transmit signed data between services in a microservices architecture.

OAuth 2.0 / OpenID Connect: JWTs are the standard format for ID tokens and access tokens in modern identity protocols.

Privacy and Security

This JWT decoder runs entirely in your browser. Your token is processed by local JavaScript — it is never sent to any server, logged, or stored. You can safely use this tool in an air-gapped environment.

As a best practice, avoid pasting long-lived production tokens into any online tool. Use short-lived tokens or tokens from non-production environments for debugging.

Frequently Asked Questions

Can I read the JWT payload without the secret? Yes. The payload is Base64URL-encoded, not encrypted. Anyone can decode and read it. This is why you should never put sensitive secrets inside a JWT payload. The signature only proves authenticity, not confidentiality.

What does “malformed JWT” mean? A JWT must have exactly three dot-separated parts, each being valid Base64URL-encoded JSON (for header and payload). Common causes of malformed JWTs include copying only part of the token, URL-encoding the dots, or accidentally including whitespace.

Why is my token expired? The exp claim contains a Unix timestamp (seconds since January 1, 1970 UTC). If the current time is past this timestamp, the token is expired. Obtain a new token by re-authenticating.

What is the difference between HS256 and RS256? HS256 uses a symmetric secret — the same key signs and verifies the token. RS256 uses an asymmetric key pair — a private key signs and a public key verifies. RS256 is preferred when multiple parties need to verify tokens without sharing a secret.

Related Tools