JWT Decoder – Decode & Inspect JSON Web Tokens Online

What Is a JWT Decoder?

A JWT decoder is a tool that reads a JSON Web Token and converts its encoded contents into a human-readable format.

JWT stands for JSON Web Token. It is commonly used by websites, APIs, mobile apps, and authentication systems to securely pass information between two parties.

A typical JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0
.
signature

A JWT normally contains three parts:

• HEADER.PAYLOAD.SIGNATURE
• Our JWT decoder separates these parts so you can inspect the data inside the token.

How to Decode a JWT Token

Using the JWT decoder is simple:

1. Copy the JWT token you want to inspect.
2. Paste it into the input field above.
3. Click Decode JWT.
4. Review the decoded header.
5. Inspect the payload and JWT claims.
6. Check the token's expiration time and signing algorithm.
7. If needed, verify the token's signature separately.

You do not normally need a secret key just to decode the header and payload.

A secret or public key is needed when you want to verify that the token was genuinely signed by a trusted issuer.

JWT Decode vs JWT Decrypt: What Is the Difference?

Many people search for terms such as JWT decrypt, JWT token decrypt, or decrypt JWT token, but most JWTs are not encrypted.

A standard JWT is usually encoded and signed, not encrypted.

This means someone who has the token can usually decode and read the header and payload.

JWT decoding

Decoding converts the encoded JWT data into readable JSON.

For example:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

JWT decryption

Decryption applies only when the token has actually been encrypted, such as with JWE — JSON Web Encryption.

Most authentication JWTs developers work with are signed JWTs, also known as JWS — JSON Web Signature.

So in most cases:

JWT decoding ≠ JWT decryption

Understanding JWT Structure

A JWT generally consists of three Base64URL-encoded sections separated by periods.

Header.Payload.Signature

For example:

xxxxx.yyyyy.zzzzz

Each section serves a different purpose.

1. JWT Header

The JWT header contains metadata describing how the token was created.

Example:

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

Common JWT header fields include:

alg

Specifies the algorithm used to sign the token.

Examples include:

• HS256
• HS384
• HS512
• RS256
• RS384
• RS512
• ES256

typ

Identifies the type of token.

For JWTs this is usually:

JWT

kid

kid means Key ID.

It can tell the receiving application which key should be used to verify the JWT signature.

This is especially common in systems that use multiple public keys or JWKS endpoints.

2. JWT Payload

The payload contains the actual information carried by the token.

This information is stored as claims.

Example:

{
  "sub": "1234567890",
  "name": "John Doe",
  "role": "admin",
  "iat": 1710000000,
  "exp": 1710003600
}

Claims may contain information such as:

• User ID
• Username
• Email address
• Roles
• Permissions
• Token issuer
• Intended audience
• Creation time
• Expiration time

Because JWT payloads can normally be decoded by anyone holding the token, you should not place sensitive secrets inside them.

JWT Claims Explained

JWT claims are pieces of information contained inside the JWT payload.

Some claims are standardized, while applications can also create their own custom claims.

iss — Issuer

Identifies who issued the token.

Example:

"iss": "https://example.com"

sub — Subject

Identifies the user or entity the token represents.

Example:

"sub": "user_12345"

aud — Audience

Specifies which application or service the token is intended for.

Example:

"aud": "api.example.com"

exp — Expiration Time

Defines when the token should stop being accepted.

Example:

"exp": 1786745412

JWT expiration values are normally stored as Unix timestamps.

A useful JWT decoder should automatically convert this value into a readable date and indicate whether the token is still valid based on time.

iat — Issued At

Shows when the JWT was created.

Example:

"iat": 1786741812

nbf — Not Before

Indicates that the token should not be accepted before a specific time.

Example:

"nbf": 1786741812

jti — JWT ID

Provides a unique identifier for a token.

Applications may use this value to track or revoke individual tokens.

JWT Expiration Checker

JWT tokens frequently include an exp claim that defines when the token expires.

For example:

{
  "exp": 1786745412
}

Our JWT decoder can convert this timestamp into a readable date.

A good token-status section should display something like:

Token Status: Valid
Issued: August 14, 2026
Expires: August 14, 2026
Remaining Validity: 42 minutes

Or:

Token Status: Expired
Expired: 2 hours ago

This can help troubleshoot authentication errors caused by expired JWT tokens.

What Is the JWT Signature?

The third part of a JWT is the signature.

The signature helps the receiving application determine whether the JWT has been modified.

A simplified signing process looks like this:

Base64Url(Header)
+
"."
+
Base64Url(Payload)
+
Secret or Private Key

The exact process depends on the signing algorithm.

For example:

HS256

RS256

ES256

If someone changes the JWT payload after it has been signed, signature verification should fail.

Decoding a JWT Does Not Verify It

This distinction is extremely important.

A JWT decoder can show you what the token contains.

That does not automatically prove that the token is authentic.

There are two separate operations:

Decode JWT

Reads the header and payload.

Verify JWT

Cryptographically checks whether the JWT signature is valid.

A token can contain perfectly readable data while still having an invalid signature.

Therefore, applications should never trust JWT claims solely because the token can be decoded.

Can You Decode JWT Without a Secret?

Yes.

In most standard JWTs, the header and payload are Base64URL encoded and can be decoded without knowing the signing secret.

For example, anyone possessing this JWT:

xxxxx.yyyyy.zzzzz

can usually decode:

xxxxx

and:

• yyyyy
• into readable JSON.

However, the signing key is still required to properly verify the token.

For symmetric algorithms such as HS256, verification typically requires the shared secret.

For asymmetric algorithms such as RS256, verification normally uses the issuer's public key.

Can Anyone Read a JWT?

Usually, yes.

If a JWT is signed but not encrypted, anyone who obtains the token can generally decode its header and payload.

This is why you should avoid placing sensitive information such as:

• Passwords
• Private API keys
• Database credentials
• Credit card information
• Private encryption keys
• Sensitive personal data

inside a normal JWT payload.

JWT signatures provide integrity and authenticity when properly verified.

They do not automatically provide confidentiality.

JWT Base64 vs Base64URL

JWT components are encoded using Base64URL, which is slightly different from standard Base64.

Base64URL is designed to work safely inside URLs.

Standard Base64 may contain characters such as:

• +
• /
• =

Base64URL typically substitutes or removes characters that can cause problems in URLs.

For example:

+ becomes -

/ becomes _

Padding characters may also be omitted.

This is why copying part of a JWT into a basic Base64 decoder sometimes requires adjustments.

A JWT decoder handles the Base64URL format automatically.

JWT Signature Algorithms

JWTs can use different cryptographic algorithms.

Some of the most common include the following.

HS256

HS256 uses HMAC with SHA-256.

It uses the same shared secret for both signing and verification.

Typical use case:

• Application → Shared Secret → JWT
• HS256 can be simple to implement but the secret must be protected carefully.
• RS256
• RS256 uses RSA with SHA-256.

It uses:

• A private key to sign JWTs
• A public key to verify JWTs

The private key can remain with the issuer while other services receive only the public key.

This makes RS256 common in distributed authentication systems.

ES256

ES256 uses elliptic-curve cryptography.

It can provide strong security with smaller key sizes than RSA.

HS256 vs RS256

The major difference is how signing keys are managed.

Neither algorithm should be chosen purely because one appears more advanced.

The correct choice depends on your authentication architecture and security requirements.

What Is JWT Authentication?

JWT authentication is an authentication method where a server issues a token after a user successfully signs in.

A common flow looks like this:

User logs in
↓
Server validates credentials
↓
Server creates JWT
↓
JWT is returned to client
↓
Client sends JWT with future API requests
↓
Server verifies JWT
↓
Access is granted or rejected

JWT authentication is often used for:

• REST APIs
• Single-page applications
• Mobile applications
• Microservices
• API gateways
• Distributed authentication systems

JWT vs Session Authentication

JWT authentication and traditional server sessions solve similar problems differently.

Session authentication

The server normally stores session information.

The browser receives a session identifier.

Example:

Browser → Session ID → Server session database

JWT authentication

The token itself can contain claims required by the application.

Example:

Browser → JWT → Server verifies token

JWT-based systems can be useful in distributed architectures, although they require careful handling of expiration, revocation, storage, and signing keys.

JWT vs OAuth

JWT and OAuth are not the same thing.

JWT is a token format.

OAuth is an authorization framework.

OAuth systems may use JWTs as access tokens, but OAuth does not require every token to be a JWT.

So:

• OAuth = authorization framework
• JWT = token format
• A JWT can also be used outside OAuth.

JWT vs Bearer Token

A bearer token is a token that grants access to whoever possesses it.

A JWT can be used as a bearer token.

For example:

Authorization: Bearer eyJhbGciOi...

However, not every bearer token is necessarily a JWT.

Some systems use opaque bearer tokens that cannot be decoded by the client.

Access Token vs ID Token

JWTs are frequently used as both access tokens and ID tokens.

However, they have different purposes.

Access token

Used to authorize access to APIs or protected resources.

ID token

Typically contains information about an authenticated user and is commonly associated with OpenID Connect.

An application should not automatically treat an ID token as an API access token.

JWT Refresh Tokens

Access tokens are usually designed to expire.

A refresh token may allow the application to obtain a new access token without forcing the user to log in again.

A simplified flow:

Login
↓
Access Token + Refresh Token
↓
Access Token expires
↓
Refresh Token sent
↓
New Access Token issued

Refresh-token architecture can improve usability but must be implemented securely.

How Long Should a JWT Token Last?

There is no single expiration time that is appropriate for every application.

Token lifetime depends on factors such as:

• Security requirements
• Type of application
• User experience
• Risk level
• Refresh-token implementation
• Token revocation capabilities

Shorter-lived access tokens reduce the amount of time a stolen token remains useful.

Long-lived tokens may reduce authentication friction but increase risk if compromised.

Where Should JWT Tokens Be Stored?

JWT storage strategy depends heavily on the application architecture.

Common locations include:

• Secure HTTP-only cookies
• Application memory
• Browser storage
• Mobile secure storage

Each method has security trade-offs.

For web applications, developers should carefully consider risks including:

• Cross-site scripting
• Cross-site request forgery
• Token theft
• Accidental token exposure

Avoid choosing a storage method simply because it is convenient.

Common JWT Errors

JWT problems frequently appear during API development and authentication debugging.

Here are several common errors.

JWT Token Expired

The current time is later than the token's exp claim.

Possible solution:

• Request a new access token
• Refresh the token
• Log in again

Invalid JWT Signature

The signature could not be verified.

Possible causes include:

• Wrong secret
• Wrong public key
• Modified payload
• Wrong signing algorithm
• Incorrect issuer configuration

JWT Token Is Invalid

This broad error may occur because:

• Token format is incorrect
• Signature validation failed
• Token expired
• Required claims are missing
• Issuer does not match
• Audience does not match
• Key ID is incorrect

Using a JWT decoder can help inspect the claims before debugging verification.

Malformed JWT

A typical signed JWT contains three sections separated by periods.

For example:

header.payload.signature

If the expected structure is missing, the token may be malformed.

How to Debug a JWT Token

If an API is rejecting your token, use this checklist:

1. Decode the JWT.
2. Confirm that the token contains three sections.
3. Check the alg value.
4. Check the iss claim.
5. Check the aud claim.
6. Check the exp timestamp.
7. Check the nbf timestamp.
8. Verify the signature with the correct key.
9. Confirm that the expected kid exists.
10. Confirm server and client clocks are synchronized.

A JWT debugger can make these checks easier by displaying token metadata in one place.

Is It Safe to Use an Online JWT Decoder?

You should be careful when pasting production authentication tokens into third-party websites.

JWTs may contain:

• User identifiers
• Email addresses
• Roles
• Permissions
• Internal IDs
• Tenant information
• API scopes

More importantly, a live JWT may grant access to an application until it expires.

For sensitive tokens, prefer tools that process the JWT entirely inside your browser or decode them locally on your own machine.

Never publish or share production access tokens unnecessarily.

JWT Security Best Practices

When building JWT-based authentication systems, consider these practices:

• Always verify JWT signatures.
• Validate token expiration.
• Validate the expected issuer.
• Validate the expected audience.
• Restrict accepted algorithms.
• Protect signing secrets and private keys.
• Avoid putting confidential data inside normal JWT payloads.
• Use short-lived access tokens when practical.
• Implement refresh-token protection carefully.
• Rotate signing keys when appropriate.
• Use HTTPS.
• Avoid logging complete authentication tokens.
• Do not trust decoded claims before verifying the token.

Should You Edit a JWT After Decoding It?

You can technically modify the decoded header or payload.

However, modifying the data invalidates the original signature.

For example, changing:

{
  "role": "user"
}

to:

{
  "role": "admin"
}

does not automatically create a valid authenticated token.

The modified token would need to be correctly signed with the appropriate signing key.

Applications must always verify JWT signatures before trusting claims.

JWT Decoder vs JWT Parser vs JWT Validator

These terms are closely related but not identical.

JWT Decoder

Converts encoded JWT data into readable header and payload values.

JWT Parser

Reads the structure and extracts claims from the JWT.

JWT Validator

Checks whether the JWT meets expected requirements, such as:

• Correct signature
• Correct issuer
• Correct audience
• Valid expiration
• Supported signing algorithm

JWT Debugger

Combines several of these tasks to help developers investigate token problems.

JWT Decoder for Developers

JWT decoding is useful when working with:

• JavaScript
• Node.js
• Python
• Java
• Spring Boot
• React
• React Native
• Angular
• Vue
• Flutter
• Kotlin
• Go
• .NET
• PHP
• Ruby
• REST APIs
• OAuth 2.0

OpenID Connect

The JWT format itself remains largely the same regardless of programming language.

You can therefore use this online decoder to inspect a token produced by almost any JWT library or framework.

Example JWT Payload

Suppose your decoded token contains:

{
  "iss": "https://auth.example.com",
  "sub": "user_2048",
  "aud": "api.example.com",
  "role": "admin",
  "iat": 1786741812,
  "exp": 1786745412
}

You can interpret it as:

• Issuer: Authentication server
• Subject: User ID
• Audience: Intended API
• Role: Admin
• Issued At: Token creation time
• Expiration: Time the token becomes invalid

The decoder makes these values easier to inspect without manually processing Base64URL strings.

Decode Your JWT Token

Paste your token into the JWT Decoder above to instantly inspect:

• JWT header
• JWT payload
• JWT claims
• Signing algorithm
• Token type
• Expiration time
• Issued-at time
• Audience
• Issuer
• Subject
• Signature information

Use the decoded information to understand your JSON Web Token, troubleshoot authentication errors, and debug API integrations faster.