What is a JWT?

A JWT (JSON Web Token) is a compact, self-contained token format defined in RFC 7519. JWTs are widely used in authentication and authorization systems to represent a user's identity, roles, and permissions. They are commonly returned by OAuth 2.0 and OIDC providers as access tokens or ID tokens.

A JWT looks like this: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9.signature. It has three parts separated by dots, each Base64-encoded.

How JWT decoding works

A JWT token has three parts: header, payload, and signature — each separated by a dot and Base64URL-encoded. Decoding means reading the Base64URL-encoded header and payload to extract the JSON data they contain. This does not require the signing secret or public key. Any tool can decode a JWT without knowing the secret.

Important: Decoding is not the same as verifying. Anyone who has a JWT can decode it to read the claims. Verification of the signature requires the correct secret or public key, and is what prevents tokens from being tampered with.

JWT header explained

The JWT header is the first part of the token. It contains metadata about the token itself — specifically:

• alg — the signing algorithm used, such as HS256, RS256, or ES256.
• typ — the token type, almost always JWT.
• kid — (optional) key ID, used when the server has multiple signing keys to identify which key was used.

JWT payload explained

The JWT payload is the second part of the token. It contains the claims — statements about the user or entity the token represents. Common standard claims include:

sub — subject

The unique identifier of the user or entity the token represents. Often a user ID.

iss — issuer

The URL or name of the service that issued the token, such as an OAuth provider.

aud — audience

The intended recipient(s) of the token — usually the API or application that should accept it.

exp — expiration time

A Unix timestamp after which the token is no longer valid. Servers reject tokens past this time.

iat — issued at

A Unix timestamp of when the token was created.

nbf — not before

A Unix timestamp before which the token is not valid.

jti — JWT ID

A unique identifier for this specific token, used to prevent replay attacks.

JWT signature explained

The signature is the third part of the token. It is created by taking the Base64URL-encoded header and payload, joining them with a dot, and signing the result using the algorithm specified in the header (e.g. HMAC-SHA256 or RSA). The signature allows the server to verify that the token has not been tampered with.

This tool does not verify the signature. It only decodes the header and payload. To verify a token, you need the signing secret or public key on the server side.

Decoding vs verifying a JWT

Decoding reads the Base64URL-encoded data in the header and payload and converts it back to JSON. No secret is required — any client can do this. Decoding is useful for debugging and inspection.

Verifying checks the cryptographic signature against the expected signing key to confirm that the token was issued by a trusted source and has not been modified. Verification requires the signing secret (for HMAC algorithms) or the public key (for RSA/ECDSA algorithms) and is done server-side.

Always verify JWT tokens on the server before trusting their claims. Never rely on client-side decoding alone for security-sensitive operations.

Security warning

Never paste real production JWT tokens containing sensitive user data into tools you do not trust or do not control. This tool runs entirely in your browser and never uploads your token, but as a general security practice, treat production tokens as sensitive credentials. Use tokens from your development or staging environments for debugging.

How JWT decoding helps API testing

When testing APIs that use JWT authentication, you often need to verify that:

• — The token was issued by the expected issuer (iss)
• — The token is intended for the correct audience (aud)
• — The token contains the right user claims (sub, roles, scopes)
• — The token expiration (exp) is set correctly
• — The signing algorithm (alg) matches what your API expects

Use this decoder to quickly inspect tokens returned by your API or authentication provider without writing any code. Works well alongside MockFlow mock APIs when testing frontend authentication flows.

Related tools

• JSON Formatter & Validator — format and validate the JSON payload from API responses.
• HTTP Status Code Explorer — understand 401 Unauthorized and other authentication-related status codes.
• Show Your IP — check your public IP for API allowlists and security configurations.

Related guides

• How to Test API Error Responses Like a Real QA Engineer
• HTTP Status Codes Every Frontend Developer Should Test
• How to Mock API Responses Without Building a Backend

Frequently asked questions

What is a JWT?

A JWT (JSON Web Token) is a compact, URL-safe token format used to securely transmit information between parties. JWTs are commonly used in authentication systems to represent a user's identity and permissions. A JWT consists of three parts separated by dots: a header, a payload, and a signature.

Does this JWT Decoder run in my browser?

Yes. The JWT Decoder runs entirely in your browser. Your token is never sent to a server, uploaded, or stored anywhere. You can use it safely for tokens from your development and staging environments.

Does decoding a JWT verify its signature?

No. Decoding and verifying are different operations. Decoding reads the Base64-encoded header and payload to display the contents. Verifying the signature requires the secret key or public key used to sign the token. This tool decodes the header and payload but does not verify the signature.

What JWT claims can I inspect?

Common JWT claims include: exp (expiration time), iat (issued at), nbf (not before), sub (subject — usually a user ID), aud (audience — intended recipients), iss (issuer — who created the token), jti (JWT ID — unique token identifier), and any custom claims your application adds.

Is it safe to paste my JWT token into this tool?

Yes, for development and staging tokens. Since the tool runs entirely in your browser and never sends data to a server, the token stays on your device. However, as a best practice, avoid pasting production tokens containing real user data into any third-party tool unless you fully understand how it works and trust the implementation.

Why is my JWT token expired?

The exp claim in the JWT payload is a Unix timestamp representing when the token expires. If the current time is past that timestamp, the token is expired and will be rejected by the server. You can inspect the exp value using this decoder to understand when the token was supposed to be valid.

Can I use this tool for API testing?

Yes. When testing APIs that use JWT authentication, this tool helps you verify that the tokens your mock API returns have the correct claims, structure, and expiration values. It is also useful for debugging authentication errors in API integration testing.