Skip to content
AgileLogics
Developer Tools

JWT Decoder: Understanding JSON Web Tokens and How to Decode Them Online

· By Alex Rivera · 13 min read
JWT Decoder: Understanding JSON Web Tokens and How to Decode Them Online

JSON Web Tokens (JWTs) are widely used in modern web applications to exchange information securely between clients, servers, and other services.

If you work with REST APIs, authentication systems, or single-page applications, you have probably encountered a JWT during API requests or user login sessions.

JWTs can look complicated because they contain long strings of encoded characters. However, understanding their structure is relatively straightforward when you know how they work.

A JWT Decoder helps developers decode and inspect JSON Web Tokens online. It allows you to view the token's header, payload, and claims in a readable format without manually separating and decoding each section.

In this guide, you will learn what JWTs are, how they work, how to decode them online, and how to inspect their contents using practical JavaScript and PHP examples.

What Is a JSON Web Token (JWT)?

A JSON Web Token (JWT) is a compact, URL-safe format for representing claims that can be transferred between two parties.

JWTs are commonly used for authentication and authorization in web applications and APIs.

A server may issue a JWT after a user successfully logs in. The client can then send that token with subsequent API requests so the server can identify the authenticated user and evaluate the token's permissions.

A JWT typically consists of three parts:

  1. Header

  2. Payload

  3. Signature

These three parts are separated by periods (.).

A typical JWT looks like this:

xxxxx.yyyyy.zzzzz

Each section has a specific purpose.

Understanding the Three Parts of a JWT

1. JWT Header

The header contains information about the token type and the cryptographic algorithm used to protect the token's integrity.

Example:

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

Common header properties include:

  • alg: Identifies the cryptographic algorithm used for the signature.

  • typ: Identifies the token type, commonly JWT.

  • kid: An optional key identifier that helps identify which key should be used for verification.

For example, HS256 represents HMAC using SHA-256, while RS256 represents RSA signature verification using SHA-256.

2. JWT Payload

The payload contains claims, which are statements about a user, an application, or other information associated with the token.

Example:

{
  "sub": "1234567890",
  "name": "John Doe",
  "email": "john@example.com",
  "role": "admin",
  "iat": 1790000000,
  "exp": 1790003600
}

JWT claims can be divided into three categories.

Registered Claims

These are standardized claim names commonly used in JWTs:

Claim

Description

iss

Issuer of the token

sub

Subject of the token

aud

Intended audience

exp

Expiration time

nbf

Not valid before

iat

Issued-at time

jti

Unique token identifier

Public Claims

Public claims are custom or standardized claims that may be used across applications. Their names should be selected carefully to avoid collisions.

Private Claims

Private claims are application-specific values agreed upon between the token issuer and consumer.

For example:

{
  "user_id": 101,
  "role": "customer",
  "subscription": "premium"
}

These claims can help an application understand the user's identity or application-specific permissions.

3. JWT Signature

The signature is used to verify that the token has not been modified and that it was signed using the expected key.

For example, an HS256 signature is generated using the encoded header, encoded payload, and a secret key.

Conceptually:

HMACSHA256(
    base64url(header) + "." + base64url(payload),
    secret
)

For asymmetric algorithms such as RS256, a private key creates the signature and the corresponding public key verifies it.

The signature is an important part of JWT security. Simply decoding a token does not verify its signature.

What Is a JWT Decoder?

A JWT Decoder is an online or software-based utility that extracts and displays the readable contents of a JSON Web Token.

Instead of manually splitting the token into sections and decoding Base64URL values, you can paste the complete JWT into a decoder.

A typical JWT Decoder displays:

  • Decoded header

  • Decoded payload

  • Token claims

  • Issued-at timestamp

  • Expiration timestamp

  • Signature section or encoded signature

A decoder makes it easier to inspect token contents during API development, authentication troubleshooting, and debugging.

Important: Decoding a JWT does not mean the token is valid or trustworthy. Signature verification and claim validation are separate security operations.

How to Decode a JWT Online

You can use an online JWT Decoder to inspect a token without writing additional code.

Follow these steps:

  1. Open the JWT Decoder tool on Agilelogics.

  2. Copy the JWT from your API response, browser developer tools, or application logs.

  3. Paste the complete token into the input area.

  4. Click the Decode option.

  5. Review the decoded header and payload.

  6. Inspect important claims such as sub, iss, aud, iat, and exp.

  7. Use the decoded information to troubleshoot your application.

A JWT decoder is especially useful when debugging authentication issues or checking whether a token contains the expected claims.

Only paste tokens that you are authorized to inspect. Avoid submitting live production tokens or credentials to third-party websites.

How to Decode a JWT Manually

A standard compact JWT contains three Base64URL-encoded sections.

You can split the token using a period and decode the first two sections.

For example:

const token = "header.payload.signature";

const parts = token.split(".");

if (parts.length !== 3) {
    throw new Error("Invalid JWT structure");
}

const header = JSON.parse(
    atob(parts[0].replace(/-/g, "+").replace(/_/g, "/"))
);

const payload = JSON.parse(
    atob(parts[1].replace(/-/g, "+").replace(/_/g, "/"))
);

console.log("Header:", header);
console.log("Payload:", payload);

This illustrates the basic process, but production code should also handle Base64URL padding and UTF-8 decoding correctly.

The signature section is not decoded into a JSON object. It contains the signature bytes represented using Base64URL encoding.

Decode JWT Using JavaScript

JavaScript applications frequently work with JWTs when communicating with REST APIs.

The following example shows how to decode a JWT header and payload safely for inspection.

function decodeBase64Url(value) {
    const base64 = value
        .replace(/-/g, "+")
        .replace(/_/g, "/");

    const padded = base64.padEnd(
        Math.ceil(base64.length / 4) * 4,
        "="
    );

    const binary = atob(padded);

    const bytes = Uint8Array.from(
        binary,
        character => character.charCodeAt(0)
    );

    return new TextDecoder().decode(bytes);
}

function decodeJWT(token) {
    const parts = token.split(".");

    if (parts.length !== 3) {
        throw new Error("Invalid JWT structure");
    }

    const header = JSON.parse(
        decodeBase64Url(parts[0])
    );

    const payload = JSON.parse(
        decodeBase64Url(parts[1])
    );

    return {
        header,
        payload,
        signature: parts[2]
    };
}

Usage:

const decoded = decodeJWT(yourJwtToken);

console.log("Header:", decoded.header);
console.log("Payload:", decoded.payload);
console.log("Signature:", decoded.signature);

This example is for inspecting a conventional signed JWT using compact serialization. It does not verify the signature, validate claims, or support every JWT-related format.

Decode JWT Using PHP

PHP applications commonly use JWTs when integrating with REST APIs, authentication services, and third-party platforms.

You can decode the header and payload using PHP's Base64 decoding functions.

function base64UrlDecode($value)
{
    $base64 = strtr($value, '-_', '+/');

    $padding = strlen($base64) % 4;

    if ($padding > 0) {
        $base64 .= str_repeat('=', 4 - $padding);
    }

    $decoded = base64_decode($base64, true);

    if ($decoded === false) {
        throw new InvalidArgumentException(
            'Invalid Base64URL value'
        );
    }

    return $decoded;
}

function decodeJWT($token)
{
    $parts = explode('.', $token);

    if (count($parts) !== 3) {
        throw new InvalidArgumentException(
            'Invalid JWT structure'
        );
    }

    $header = json_decode(
        base64UrlDecode($parts[0]),
        true,
        512,
        JSON_THROW_ON_ERROR
    );

    $payload = json_decode(
        base64UrlDecode($parts[1]),
        true,
        512,
        JSON_THROW_ON_ERROR
    );

    return [
        'header' => $header,
        'payload' => $payload,
        'signature' => $parts[2]
    ];
}

Usage:

$decoded = decodeJWT($yourJwtToken);

print_r($decoded['header']);
print_r($decoded['payload']);

This example decodes token contents for inspection. It does not establish that the token was issued by a trusted party.

For production authentication, use a maintained JWT library and configure signature verification and claim validation correctly.

Understanding Important JWT Claims

When debugging JWT authentication, some claims deserve particular attention.

Expiration Time (exp)

The exp claim specifies the time after which the token must not be accepted.

For example:

{
  "sub": "12345",
  "exp": 1790003600
}

The value is a Unix timestamp in seconds.

In JavaScript, you can convert it into a readable date:

const expirationDate = new Date(
    payload.exp * 1000
);

console.log(expirationDate);

If the token has expired, the server should reject it according to its validation rules.

Issued At (iat)

The iat claim indicates when the token was issued.

{
  "iat": 1790000000
}

It can help developers understand when a token was created.

Issuer (iss)

The iss claim identifies the system or service that issued the token.

For example:

{
  "iss": "https://auth.example.com"
}

The receiving application should verify that the issuer matches an expected trusted value.

Audience (aud)

The aud claim identifies the intended recipient or recipients of the token.

For example:

{
  "aud": "https://api.example.com"
}

An application should validate the audience to ensure the token was intended for that service.

JWT Decoding vs. JWT Verification

One of the most important concepts to understand is the difference between decoding and verification.

Feature

JWT Decoding

JWT Verification

Reads header

Yes

Yes

Reads payload

Yes

Yes

Displays claims

Yes

Yes

Checks signature

No

Yes

Confirms trusted issuer

No

Can validate

Checks expiration

Can display it

Must validate

Establishes token authenticity

No

Only when correctly configured

A JWT decoder simply reveals the encoded information.

A JWT verifier checks whether the token's signature is valid using the appropriate key and algorithm. A secure application should also validate relevant claims, including issuer, audience, expiration, and other application-specific requirements.

Never trust a JWT simply because its payload looks correct after decoding.

Is a JWT Encrypted?

A common misunderstanding is that JWT payloads are encrypted.

Most JWTs used for API authentication are signed but not encrypted.

A signed JWT protects integrity and authenticity when its signature is properly verified, but its header and payload are generally readable by anyone who has the token.

For example, a token containing the following payload:

{
  "email": "john@example.com",
  "role": "admin"
}

can be decoded by anyone who obtains the token.

If confidential information must be protected inside a token, use an appropriate encryption mechanism such as JSON Web Encryption (JWE), or avoid placing sensitive information in the token.

Never store passwords, private keys, or sensitive personal information in an ordinary signed JWT payload.

Common JWT Errors and Troubleshooting Tips

1. Invalid JWT Structure

A conventional signed compact JWT should contain three sections separated by periods.

If a token has missing sections or an unexpected format, decoding may fail.

2. Invalid Base64URL Encoding

JWTs use Base64URL encoding, which differs from standard Base64.

Base64URL uses:

  • - instead of +

  • _ instead of /

  • Optional omitted padding (=)

Using standard Base64 decoding without handling these differences can produce errors.

3. Token Has Expired

If the current time is later than the token's expiration time, the receiving application should reject it.

Check the exp claim and the application's clock configuration.

4. Invalid Signature

A token may have a correctly formatted header and payload but still contain an invalid signature.

This can happen when:

  • The token has been modified.

  • The wrong verification key is being used.

  • The signing algorithm does not match the expected configuration.

  • The token was issued by an untrusted source.

5. Invalid Issuer or Audience

A valid signature alone is not sufficient for every application.

The receiving service should check whether the issuer and audience match the expected values.

6. Algorithm Confusion or Misconfiguration

Applications must not blindly trust the alg value supplied in an unverified token header.

Configure an explicit allowlist of acceptable algorithms and use a trusted JWT library to verify signatures.

Common Use Cases of JWTs

JWTs are used in many types of modern applications.

User Authentication

A server can issue a token after successful login. The client then includes it in subsequent API requests.

REST API Authorization

APIs can use JWT claims to evaluate access permissions and identify the intended user or service.

Single Sign-On (SSO)

JWT-based systems can support authentication information exchange between participating applications.

Microservices Communication

Services can exchange signed tokens to carry identity and authorization information between systems.

Mobile Application Authentication

Mobile applications can use access tokens when communicating with backend APIs.

The exact security design depends on the authentication architecture, token lifetime, storage method, and verification requirements.

Frequently Asked Questions (FAQs)

1. What is a JWT Decoder?

A JWT Decoder is a tool that extracts and displays the readable header and payload of a JSON Web Token. It helps developers inspect token claims and troubleshoot authentication-related issues.

2. Can I decode a JWT without a secret key?

Yes. You can decode the header and payload of a conventional signed JWT without knowing the secret or private key. However, you cannot verify its signature without the appropriate verification key.

3. Is decoding a JWT the same as verifying it?

No. Decoding reveals the token's contents, while verification checks its signature and helps establish whether it was issued by a trusted party and has not been modified.

4. Can anyone decode a JWT?

Anyone who obtains a conventional signed JWT can generally decode its header and payload. This is why sensitive information should not be stored in ordinary signed JWT payloads.

5. What are the three parts of a JWT?

A conventional signed compact JWT contains a header, payload, and signature. Each section is separated by a period.

6. What does the JWT expiration claim mean?

The exp claim specifies the expiration time of a token as a NumericDate value, normally represented as seconds since the Unix epoch. A token should not be accepted after that time.

7. What is the difference between JWT and Base64?

JWT is a token format that commonly uses Base64URL encoding for its header, payload, and signature representation. Base64 is an encoding method, not an authentication or security mechanism.

8. Can I edit a JWT payload after decoding it?

You can modify the decoded data locally, but changing the payload changes the token. The original signature will no longer match, so a properly verifying application should reject the modified token.

9. Is a JWT safe to store in localStorage?

There is no universally safe storage choice. JavaScript-accessible storage such as localStorage exposes tokens to theft if an application has an XSS vulnerability. HttpOnly, Secure, appropriately configured cookies can reduce that particular risk, but require suitable CSRF protections and careful cookie configuration.

10. What is the difference between JWT and JWE?

A signed JWT commonly uses JSON Web Signature (JWS) to protect integrity and authenticity. JSON Web Encryption (JWE) provides encryption to protect the token's contents from unauthorized readers.

Conclusion

JSON Web Tokens play an important role in modern authentication and API communication. Understanding their structure and claims makes it easier to troubleshoot login issues, inspect API responses, and work with authentication systems.

A JWT Decoder simplifies this process by allowing developers to inspect token headers and payloads in a readable format.

Whether you are debugging a REST API, investigating an expired token, or learning how JWT authentication works, decoding a token is a useful first step.

Try the Agilelogics JWT Decoder to decode and inspect JSON Web Tokens online.


Related Developer Tools

Explore these related tools on Agilelogics:

Explore more developer utilities on Agilelogics.

JWT Decoder Online Decode JWT Online JSON Web Token Decoder JWT Token Decoder JWT Token Structure JWT Header and Payload JWT Authentication JWT Claims JWT Verification Decode JSON Web Token

Written by

Alex Rivera

AI/ML writer covering AI assistants, coding tools, and generative AI platforms — pricing, capabilities, and how they actually compare.

Share