How to Decode and Inspect JSON Web Tokens (JWT): Header, Payload, and Signature Explained

If you build modern web applications, REST APIs, or microservices, you work with JSON Web Tokens (JWT) every single day. They power user sessions in Next.js, carry OAuth2 permissions from Google and GitHub, and authenticate requests across cloud architectures.

Yet when developers need to inspect a token to check permissions, user IDs, or expiration timestamps, they frequently paste production tokens into public online web debuggers. If that token contains customer email addresses or private claims, pasting it into a third-party server creates an immediate security and compliance violation.

This guide explains how JWTs are structured at the bitwise level, why they use Base64url encoding, how to decode them locally in your browser, and how to format the extracted JSON payloads using Synctoolo's Base64 Encoder / Decoder and JSON Formatter.

The Anatomy of a JWT: Three Parts Separated by Dots

A JSON Web Token is a compact, URL-safe string composed of three distinct sections separated by periods (.):

header.payload.signature

Each section serves a specific cryptographic function:

1. The Header: Algorithm and Token Type

The header typically contains two fields: the signing algorithm being used (such as HS256 or RS256) and the token type (JWT):

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

2. The Payload: Claims and User Identity

The payload stores the actual claims: statements about an entity (typically the user) and metadata. Standard registered claims defined by RFC 7519 include:

• sub (Subject): The unique identifier of the user.
• iat (Issued At): Unix epoch timestamp when the token was created.
• exp (Expiration Time): Unix epoch timestamp after which the token is invalid.
• iss (Issuer): The identity provider that generated the token.

3. The Signature: Cryptographic Integrity

The signature ensures that the token has not been tampered with in transit. It is generated by taking the encoded header, the encoded payload, a secret key, and hashing them with the specified algorithm:

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

Why JWTs Use Base64url Instead of Standard Base64

Standard Base64 contains the plus symbol (+) and forward slash (/). In HTTP Authorization headers and URL query strings, these characters cause parsing conflicts:

• + is frequently interpreted by web servers as a space.
• / is interpreted by routers as a path separator.
• = padding characters interfere with query parameter syntax.

How to Decode a JWT in 1 Line of Client-Side JavaScript

Because the header and payload are simply Base64url-encoded JSON strings (NOT encrypted), you can decode any JWT in pure JavaScript without external libraries:

function parseJwtPayload(token) {
  const base64Url = token.split('.')[1];
  const base64 = base64Url.replace(/-/g, '+').replace(/_/g, '/');
  const jsonPayload = decodeURIComponent(
    atob(base64)
      .split('')
      .map(c => '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2))
      .join('')
  );
  return JSON.parse(jsonPayload);
}

Need to inspect and format an encoded token right now? Paste the middle section into our client-side Base64 Decoder and format the resulting object with our JSON Formatter. Your token executes 100% in local browser memory with zero network transmission.