# How to Decode a JWT Token

> Inspect and decode JSON Web Tokens to view the header, payload, and signature without any server-side processing.

- URL: https://www.browserutils.dev/how-to/decode-jwt-token
- Published: 2026-03-05
- Updated: 2026-03-16

---

## Step 1: Paste your JWT

Copy the full JWT string (the three dot-separated segments) and paste it into the input field.

## Step 2: View the decoded parts

The tool splits the token into its header, payload, and signature. The header and payload are decoded from Base64 and displayed as formatted JSON.

## Step 3: Check claims and expiration

Review the payload claims including iss, sub, exp, and iat. The tool highlights whether the token is expired.

## Step 4: Copy individual sections

Copy the header, payload, or full decoded output separately for use in debugging or documentation.

JSON Web Tokens show up everywhere — OAuth flows, API authentication, single sign-on systems, and session management. When you need to quickly check what claims a token carries or whether it has expired, the [JWT Decoder](/tools/jwt-decoder) lets you inspect it without writing any code or hitting a server.

## Understanding JWT structure

A JWT is made up of three parts separated by dots: `header.payload.signature`. The header and payload are Base64url-encoded JSON objects, and the signature is a cryptographic hash that verifies the token has not been tampered with.

The **header** typically contains the algorithm used for signing (like `HS256` or `RS256`) and the token type. The **payload** holds the claims — standard ones like `iss` (issuer), `sub` (subject), `exp` (expiration timestamp), and `iat` (issued at), along with any custom claims the application adds. The **signature** is computed from the header, payload, and a secret key or private key.

## Why this matters

Decoding a JWT in the browser is safe because you are only reading the Base64-encoded data — you are not verifying the signature. However, you must understand an important security principle: **never trust a JWT on the client side alone.** A decoded JWT tells you what the token *claims*, but only server-side signature verification confirms those claims are authentic. An attacker can craft a JWT with any payload they want — only the signature check catches the forgery.

This means client-side JWT decoding is useful for debugging and UI purposes (like showing the user's name or checking if a token looks expired before making an API call), but all authorization decisions must happen on the server.

## Tips and best practices

- **Check the `exp` claim first** when debugging authentication failures. Token expiration is the most common reason API calls start returning 401 errors.
- **Look at the `alg` field in the header.** If it says `none`, that is a red flag — it means the token is unsigned and should be rejected by any properly configured server.
- **Compare `iat` and `exp`** to understand the token's lifetime. Short-lived tokens (5-15 minutes) are more secure but require a refresh token flow.
- **Watch for clock skew.** JWT timestamps are Unix epoch seconds. If your server and auth provider clocks are slightly out of sync, tokens may appear expired prematurely.
- **Never paste production tokens into untrusted websites.** Use a tool you trust, or decode locally with `echo '<payload>' | base64 -d` in your terminal.

## Common issues

- **"Invalid token" errors:** Make sure you are pasting the complete token, including all three dot-separated parts. Copying from logs sometimes truncates long strings.
- **Expired tokens that look valid:** The `exp` value is a Unix timestamp in seconds, not milliseconds. If you are comparing it manually, make sure you are using the right unit.
- **Unexpected claims:** Some identity providers nest user info inside a custom claim like `https://example.com/claims` rather than using standard claim names. Check your provider's documentation if expected fields are missing.