JWT Decoder

How to decode a JWT

1. 1
   Copy the token

   Take the JWT from the Authorization header in your browser's network tab, a cookie, local storage or a login response. Copying "Bearer " along with it is fine.

2. 2
   Paste it into the box

   The prefix, quotes, spaces and line breaks are stripped automatically, and the token is split into its color-coded header, payload and signature.

3. 3
   Check the algorithm and status

   Read alg and typ from the header chips, and the status badge for whether the token is valid, expired or not active yet. A red warning appears if alg is "none".

4. 4
   Read the claims

   Use the decoded payload and the claims table to confirm the issuer, subject and audience, and to see exp, nbf and iat as UTC and local times.

5. 5
   Copy what you need, then verify on the server

   Copy the header or payload JSON for a bug report or test. Remember the signature has not been checked: your API must verify it before trusting any claim.

What is inside a JWT

A JSON Web Token, defined in RFC 7519, is three Base64URL strings joined by dots. Here is a complete token with fake data, signed with the demo secret frost-rank-demo-secret so you can verify it with any JWT library:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyXzEwNDIiLCJhdWQiOiJodHRwczovL2FwaS5leGFtcGxlLmNvbSIsImV4cCI6MTc5MDg0ODgwMCwibmJmIjoxNzkwODQ1MjAwLCJpYXQiOjE3OTA4NDUyMDAsImp0aSI6IjdmM2M5YTFlLWRlbW8iLCJuYW1lIjoiSmFuZSBFeGFtcGxlIiwicm9sZSI6ImVkaXRvciJ9.9Kvkds8sF4oOJCyOI4Qy3BTgGtWfDJecX5g3tX6f15M

• Header says how the token was signed. Decoded, the first part is:

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

• Payload holds the claims: statements about the user and the token itself. Decoded, the second part is:

{
    "iss": "https://auth.example.com",
    "sub": "user_1042",
    "aud": "https://api.example.com",
    "exp": 1790848800,
    "nbf": 1790845200,
    "iat": 1790845200,
    "jti": "7f3c9a1e-demo",
    "name": "Jane Example",
    "role": "editor"
}

• Signature is an HMAC-SHA256 of the first two parts (exactly as they appear, dot included) computed with the secret. It's 32 raw bytes, which is why it's 43 characters. Change one character of the header or payload and the signature no longer matches.

The timestamps in this token put iat and nbf at 09:00 UTC on 1 October 2026 and exp one hour later, so pasting it into the decoder shows it as expired. The "Load example" button creates a fresh token with the same claims, dated to the moment you click, so you can see a live countdown instead. None of the three parts contains +, / or =, and none ever will: wherever those characters would appear, a JWT uses - and _ and drops the padding. The URL-safe Base64 decoder accepts that alphabet when you need to decode a single part by hand.

Registered claims reference

RFC 7519 reserves seven short claim names. None are mandatory, but when present they have fixed meanings that JWT libraries check for you:

All three times are NumericDate values: whole seconds since 1 January 1970 UTC. A value with 13 digits is milliseconds from JavaScript's Date.now(), a common bug that makes tokens look valid for thousands of years; the decoder flags it. Everything else in the payload, like name and role above, is a custom claim your own application defines. To format and validate the JSON payload on its own, for example when building test fixtures, paste the copied payload there.

JWT is encoded, not encrypted

Base64URL is a way of writing bytes as text, not a way of hiding them. Anyone who gets a token, from a log file, a screenshot, a browser extension or a shared HAR file, can read every claim in it without any key. The signature protects integrity, not confidentiality: it stops people from changing the payload, not from reading it. Keep that in mind when designing tokens:

• Never put secrets in the payload. No passwords, API keys, card numbers or personal data you wouldn't print in a log. An opaque user ID in sub is enough.
• Always verify the signature server-side, on every request, with a maintained library. Decoding a token and trusting its role claim without verification lets anyone grant themselves admin.
• Keep expiry short. A stolen JWT stays usable until exp, because most servers can't revoke it early. Minutes for access tokens, with a separate refresh token, is the usual pattern.
• Pin the algorithm. Tell your library exactly which alg to accept. Never accept none, and never let the token's own header choose between an HMAC secret and a public key.
• Be careful where you paste tokens. A live production token in a random website is a leaked credential. This decoder runs entirely in your browser and sends nothing anywhere, but the safest token to debug with is still one from a test environment, or one that has already expired.

Common JWT errors and what they mean

Token expired

The current time is past exp. If tokens expire sooner than expected, compare the issuing and verifying servers' clocks; a few minutes of drift is enough. Fix drift with NTP and a small leeway, not by lengthening every token's lifetime.

Invalid signature

The signature doesn't match the header and payload. Usual causes: the API verifies with a different secret or key than the issuer signed with, keys were rotated and the kid in the header points to an old key, the algorithm is pinned to RS256 but the token says HS256, or the token was edited or truncated in transit.

Wrong audience or issuer

The signature is fine, but aud or iss doesn't match what the API is configured to expect. This often happens when a staging token is sent to production, or a token issued for one API is reused for another. Decode the token here and compare both values character by character, including trailing slashes.

Malformed token

The parser couldn't split or decode it. Typical reasons are a leftover Bearer prefix or surrounding quotes, a token cut off by a log line limit, a line break added by an email client, or a five-part encrypted JWE where a three-part JWT was expected. This decoder cleans up the first three cases and names the broken part for the rest.

If the token comes from a cookie or a header, it also helps to check a URL's response and security headers, such as whether an auth cookie is set with Secure and HttpOnly. The HTTP security headers guide explains which ones matter.

Code examples

JavaScript: decode without a library

Fine for reading claims in the browser, for example to show a session countdown. Never use it to make an authorization decision.

function decodeJwtPart(part) {
  // Base64URL → Base64: swap the URL-safe characters back and restore the padding.
  let base64 = part.replace(/-/g, '+').replace(/_/g, '/');
  base64 += '='.repeat((4 - (base64.length % 4)) % 4);

  const bytes = Uint8Array.from(atob(base64), (c) => c.charCodeAt(0));
  return JSON.parse(new TextDecoder().decode(bytes)); // handles non-ASCII names
}

const [header, payload] = token.split('.').slice(0, 2).map(decodeJwtPart);
const expired = payload.exp * 1000 <= Date.now();

PHP: read the payload, then verify properly

Manual decoding is useful for logging or debugging only:

<?php
[$header, $payload] = explode('.', $jwt);
$claims = json_decode(base64_decode(strtr($payload, '-_', '+/')), true);
echo $claims['sub']; // NOT trustworthy yet: nothing has been verified

To actually trust a token, verify it with a library such as firebase/php-jwt (composer require firebase/php-jwt). JWT::decode() checks the signature, exp and nbf, and throws if any check fails. The Key object pins the algorithm:

<?php
use Firebase\JWT\ExpiredException;
use Firebase\JWT\JWT;
use Firebase\JWT\Key;
use Firebase\JWT\SignatureInvalidException;

JWT::$leeway = 60; // seconds of allowed clock skew

try {
    $claims = JWT::decode($jwt, new Key($secret, 'HS256'));
} catch (ExpiredException $e) {
    // 401: token expired
} catch (SignatureInvalidException $e) {
    // 401: wrong key, or the token was modified
}

// The library doesn't know your issuer or audience: check them yourself.
if ($claims->iss !== 'https://auth.example.com' || $claims->aud !== 'https://api.example.com') {
    // 401: token was issued for someone else
}

Laravel: where verification belongs

Verify tokens in one place, before any controller runs: a custom guard or a route middleware that reads $request->bearerToken(), verifies it as above, and sets the authenticated user. Controllers should then rely on auth()->user(), never decode the token themselves. If you use Laravel Passport, its auth:api guard already verifies its own JWT access tokens. Laravel Sanctum's API tokens aren't JWTs at all: they're random strings looked up in the database, so there's nothing to decode.

Frequently asked questions