How to Decode JWT Tokens, Understand Base64URL Claims, and Verify HMAC Signatures

JSON Web Tokens (JWT) defined in IETF RFC 7519 are the industry standard for stateless API authentication, OAuth 2.0 access tokens, and OpenID Connect identity assertions. Yet one of the most dangerous misconceptions in web development is assuming that a signed JWT hides its contents from the client, or pasting live production bearer tokens into server-side debugging websites that log request payloads.

1. Anatomy of a Three-Part JWT (Header.Payload.Signature)

Every compact JWS (JSON Web Signature) token consists of three Base64URL-encoded segments separated by periods (.):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c3JfOTg0MiIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTc5MjcxMzYwMCwiZXhwIjoxNzkyNzE3MjAwfQ.SignatureBytesHere
__________________________________/ __________________________________________________________________________________________/ ________________/
            1. Header                                                2. Payload (Claims)                                            3. Signature

Part 1: The JOSE Header

Decoded from Base64URL, the header specifies the token type and the cryptographic signing algorithm:

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

Part 2: The Payload (Registered & Custom Claims)

The second segment contains the JSON claims asserting who the user is and when the token expires:

{
  "sub": "usr_9842",
  "role": "admin",
  "iat": 1792713600,
  "exp": 1792717200
}

You can inspect the decoded JSON header, payload claims, and live expiration countdown (exp / iat) 100% locally in your browser without transmitting your token over the network using the EverySolve JWT Token Decoder.

2. Encoding Is Not Encryption: Standard Base64 vs. Base64URL

A signed JWT (JWS) guarantees integrity and authenticity (nobody can tamper with "role": "user" to make it "role": "admin" without invalidating the signature), not confidentiality. Anyone who intercepts or inspects a JWT can decode its header and payload in milliseconds because they are simply encoded using Base64URL (RFC 4648 Section 5).

How does Base64URL differ from standard Base64 (RFC 4648 Section 4)?

• Standard Base64 uses + (index 62), / (index 63), and = for padding—all three of which have special reserved meanings inside URLs and HTTP headers.
• Base64URL replaces + with - (hyphen), replaces / with _ (underscore), and strips trailing = padding characters so the token can be safely passed in URLs, cookies, and Authorization: Bearer <token> headers.

Never store plaintext passwords, credit card numbers, Aadhaar/SSN identifiers, or private API keys inside an unencrypted JWT payload. Test encoding and decoding raw UTF-8 strings and payloads with the EverySolve Base64 Encoder / Decoder.

3. How HS256 (HMAC-SHA256) Signatures Prevent Tampering

When the header specifies "alg": "HS256", the authentication server computes the third segment using a keyed Hash-based Message Authentication Code (HMAC-SHA256, RFC 2104) over the exact ASCII bytes of the first two segments joined by a dot:

Because an attacker does not possess the server's SecretKey, modifying even a single character in the payload produces a completely different 256-bit HMAC digest, causing the server's constant-time signature verification check to reject the request with 401 Unauthorized.

You can compute hexadecimal HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 digests for message strings and <Base64URL(Header)>.<Base64URL(Payload)> signing inputs directly in your browser using the EverySolve HMAC Signature Generator (note that compact JWTs encode those raw 32-byte HMAC digests as 43-character Base64URL strings without = padding).

4. Three Critical JWT Security Best Practices for Production

1. Reject "alg": "none" and Prevent RS256-to-HS256 Key Confusion: Early JWT libraries allowed attackers to set "alg": "none" in the header and strip the signature. An even subtler vulnerability is algorithm confusion: if a server expects an asymmetric RS256 token (signed with a private RSA key and verified with a public RSA key) but does not enforce the algorithm, an attacker can change the header to "alg": "HS256" and sign the token symmetrically using the server's publicly available RSA public key bytes as the HMAC secret. Always pass an explicit whitelist of allowed algorithms (such as ['HS256'] or ['RS256']) to your backend verification function.
2. Use High-Entropy Cryptographic Signing Secrets: If you sign tokens with HS256 using a weak dictionary word or short passphrase, an attacker can brute-force the secret offline using a single captured JWT because HMAC verification requires no network round-trip. IETF RFC 7518 Section 3.2 requires an HS256 secret key to have at least 256 bits (32 bytes / 64 hex characters) of cryptographic entropy. Generate CSPRNG-backed 256-bit and 512-bit signing secrets locally with the EverySolve Secret Key & API Token Generator.
3. Keep Access Token Lifetimes Short (exp): Because stateless JWTs cannot be revoked before they expire without maintaining a server-side denylist, keep access token lifetimes short (e.g., 15 to 60 minutes) and rotate refresh tokens securely.

For related cryptographic and payload validation workflows, read our guides on Generating Secure Passwords and Verifying Cryptographic Hashes and Validating JSON Schema Payloads.