Can this tool verify the JWT signature?

No. Signature verification requires the secret key (HS256) or public key (RS256/ES256). This is a client-side decoder — verification must be done server-side.

What do the colours mean in the token preview?

Red = Header (algorithm and metadata), Violet = Payload (claims and user data), Cyan = Signature (cryptographic hash). This matches the colour convention used by jwt.io.

Are JWT claims encrypted?

No. The header and payload are Base64URL encoded (not encrypted). Anyone with the token can decode and read the claims. Never put passwords or sensitive data in a JWT payload.

What is the exp claim?

exp (Expiration Time) is a Unix timestamp after which the token is no longer valid. Servers check this on every request. This decoder shows the time remaining or how long ago the token expired.

Can I decode tokens from any provider?

Yes. JWTs have a standard structure regardless of which provider or library created them (Auth0, Firebase, Cognito, Keycloak, custom servers, etc.).

What is the nbf claim?

nbf (Not Before) is a Unix timestamp before which the token must not be accepted. Servers reject tokens where the current time is before the nbf value.

JWT Decoder

Decode, inspect, and debug JSON Web Tokens instantly

Try sample:

Encoded Token

Free JWT Decoder — Decode & Inspect JSON Web Tokens Online

A JSON Web Token (JWT) is a compact, digitally signed data format used widely in modern web authentication and authorisation systems. When you log in to a web application, the server often responds with a JWT — a self-contained token that tells the application who you are and what you are allowed to do, without the server needing to query a database on every request.

The OmniWebKit JWT Decoder lets you paste any JWT token and instantly see the decoded contents in a clean, readable format. The tool separates the three parts of the token — Header, Payload, and Signature — and displays them with clear labels, colour coding, and human-readable timestamps for date claims like exp (expiration), iat (issued at), and nbf (not before). If the token has already expired, a red banner tells you how long ago it expired. If it is still valid, a green banner shows how much time is left.

Three sample tokens are included — a basic token, an expired token, and a rich-claims token with multiple standard claims — so you can explore the decoder without needing a real token. All decoding happens entirely in your browser. No token data is sent to any server.

The Three Parts of a JWT Explained

Every JWT consists of three Base64URL-encoded parts joined by dots: header.payload.signature. Understanding each part is essential for working with authentication systems.

Header

The header contains metadata about the token itself. It always specifies the type of token (typ: "JWT") and the signing algorithm used to create the signature (alg). Common algorithms include HS256 (HMAC-SHA256, symmetric), RS256 (RSA-SHA256, asymmetric), and ES256 (ECDSA-SHA256). The header may also include a Key ID (kid) to help the server select the correct key for verification. The header is Base64URL encoded — not encrypted. Anyone who has the token can read it.

Payload (Claims)

The payload contains the "claims" — statements about an entity (usually the user) and additional metadata. Standard registered claims include sub (subject/user ID), iss (issuer/auth server URL), aud (audience/intended app), exp (expiration Unix timestamp), iat (issued-at Unix timestamp), nbf (not-before timestamp), and jti (unique token ID). Private claims are custom fields added by your application, such as role, email, name, scope, or any other data the app needs. Like the header, the payload is Base64URL encoded and readable by anyone with the token — never put sensitive secrets in it.

Signature

The signature is created by the server using the encoded header, the encoded payload, and a secret key. It is what makes the JWT tamper-proof. If anyone modifies the header or payload after the token is issued, the signature becomes invalid and the server will reject the token. For HS256, a shared secret key is used. For RS256, the server signs with a private key and recipients verify with the server's public key. This decoder shows the raw signature but does not verify it — signature verification requires the secret or public key and is performed server-side.

Standard JWT Claims Reference

Claim	Full Name	Type	Description
iss	Issuer	String	The URL of the server that issued the token (e.g. https://auth.example.com)
sub	Subject	String	The unique identifier of the user or entity the token represents
aud	Audience	String/Array	The intended recipient(s) of the token — usually your application's client ID
exp	Expiration Time	Unix timestamp	After this time the token is invalid. Validated server-side on every request.
nbf	Not Before	Unix timestamp	The token is not valid before this time. Useful for delayed activation.
iat	Issued At	Unix timestamp	When the token was created. Used to determine how old the token is.
jti	JWT ID	String	A unique identifier for this specific token. Used to prevent token replay attacks.

Frequently Asked Questions

Is it safe to paste my JWT here?+

This tool decodes JWTs entirely in your browser. No data is sent to any server. That said, treat your JWTs like passwords — avoid pasting valid production tokens on any public website. Use sample tokens or expired tokens for testing.

Why can't I verify the signature here?+

Signature verification requires either the secret key (for HS256) or the server's public key (for RS256/ES256). This decoder is a client-side tool that decodes and displays the token contents — verification must be done server-side with the appropriate key.

What is the difference between HS256 and RS256?+

HS256 (HMAC-SHA256) uses a shared symmetric secret key — the same key is used to sign and verify. RS256 (RSA-SHA256) uses an asymmetric key pair: a private key to sign and a public key to verify. RS256 is preferred in distributed systems where multiple services need to verify tokens without sharing a secret.

Why does the payload say the token is expired?+

The exp claim (expiration time) is a Unix timestamp. If the current time is past that timestamp, the token is expired. Expired tokens are rejected by servers. This decoder shows human-readable expiry information to help you debug token issues.

Can I decode JWT tokens from any provider?+

Yes. JWTs have a standard structure regardless of which library or provider created them (Auth0, Firebase, Cognito, Keycloak, custom servers, etc.). Any valid JWT with 3 dot-separated Base64URL-encoded parts can be decoded here.

Are claims in the payload encrypted?+

No. The payload (and header) are Base64URL encoded, which is just a way of converting binary data to text. It is not encryption. Anyone with access to the token can decode and read the claims. Never put passwords, credit card numbers, or other sensitive data in a JWT payload.

What is the JWT token format?+

A JWT is three Base64URL-encoded strings joined by dots: header.payload.signature. The header and payload are JSON objects. The signature is a cryptographic hash of the header and payload using the algorithm specified in the header.

What does "not before" (nbf) mean?+

The nbf claim specifies a time before which the token must not be accepted. Servers should reject tokens where the current time is before the nbf timestamp. This is useful for issuing tokens in advance that should only become valid at a specific future time.