Are JWTs (JSON Web Tokens) Base64 Encoded?

Published on 2026-02-28

JSON Web Tokens (JWTs) have become the industry standard for securing APIs, handling authentication, and passing verifiable claims between parties. If you’ve ever looked at a JWT, you know it looks like a long, seemingly random string of characters divided by two periods (e.g., xxxxx.yyyyy.zzzzz).

Because they look like scrambled text, a common question developers ask is: are jwts base64 encoded?

The short answer is yes, but with a very important distinction. JWTs are not encoded using standard Base64; they are encoded using a specific variant called Base64URL.

In this article, we will break down the structure of a JWT, explain exactly how and why it uses Base64URL encoding, and discuss the security implications you need to be aware of.

Key Takeaways

• Yes, they are encoded: The parts of a JWT are encoded to ensure they can be safely passed in HTTP headers and URLs.
• Base64URL, not Standard Base64: JWTs use the Base64URL variant, which replaces the + and / characters to prevent URL parsing errors, and omits = padding.
• Not Encrypted: Base64URL encoding provides format safety, not security. Anyone can easily decode the header and payload of a JWT.
• Three Parts: A JWT consists of a Header, a Payload (Claims), and a Signature—all of which utilize Base64URL encoding.

The Structure of a JWT

To understand how encoding applies to a JWT, we must look at its three-part structure. A JWT always consists of three strings separated by dots (.):

Header.Payload.Signature

1. The Header

The header is a JSON object that typically consists of two parts: the type of the token (JWT) and the signing algorithm being used (such as HMAC SHA256 or RSA).

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

This JSON object is then Base64URL encoded to form the first part of the JWT.

2. The Payload (Claims)

The second part is the payload, which contains the claims. Claims are statements about an entity (typically the user) and additional data (like expiration time, user ID, or roles).

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Like the header, this JSON object is Base64URL encoded to form the second part of the JWT.

3. The Signature

To create the signature part, you take the encoded header, the encoded payload, a secret (or private key), and the algorithm specified in the header, and sign it. The resulting binary cryptographic signature is also Base64URL encoded to form the final part of the string.

Why Do JWTs Use Base64URL Instead of Standard Base64?

So, are jwts base64 encoded? Yes, but they use the Base64URL variant.

Standard Base64 encoding relies on an alphabet of 64 characters: A-Z, a-z, 0-9, +, and /. It also uses the = character for padding at the end of the string.

The problem is that JWTs are often passed in HTTP environments—specifically in URL query parameters or HTTP Authorization headers. * In a URL, the + character is often interpreted as a space. * The / character is used as a path separator. * The = character is used to separate query parameters and values.

If a standard Base64 string were passed in a URL, the web server or browser might misinterpret those characters, corrupting the token.

Base64URL solves this by making slight modifications: 1. The + character is replaced with a hyphen (-). 2. The / character is replaced with an underscore (_). 3. The trailing = padding characters are omitted entirely.

This ensures the resulting string is perfectly URL-safe and can be passed anywhere on the web without being modified or corrupted by parsers.

Encoding vs. Encryption: A Critical Security Warning

Because JWTs look like gibberish, junior developers often mistakenly believe the data inside a JWT is encrypted and safe from prying eyes. This is a dangerous misconception.

Base64URL is merely an encoding format, not encryption.

Anyone who gets their hands on a standard JWT can simply take the Header and Payload sections, run them through a Base64URL decoder, and read the JSON data in plain text.

For example, if you place a user's password, social security number, or private API keys inside the JWT payload, anyone who intercepts the token can read it.

The security of a standard JWT lies in the Signature. The signature guarantees integrity—meaning the server can verify that the token hasn't been tampered with since it was created. But it does not provide confidentiality. If you need confidentiality, you must use a JWE (JSON Web Encryption) rather than a standard JWS (JSON Web Signature).

Conclusion

To answer the question, are jwts base64 encoded: Yes, the Header, Payload, and Signature of a JWT are all encoded. However, they strictly use the Base64URL variant to ensure they remain safe when transmitted via URLs and HTTP headers. Understanding that JWTs are just Base64URL encoded JSON objects is vital for developers, as it highlights the critical rule of token design: never put sensitive, secret information inside a standard JWT payload, because anyone can easily decode and read it.

FAQs

Q: How can I decode a JWT to read its contents? A: You can easily decode a JWT by splitting it at the periods, taking the first or second part, and passing it to a Base64 decoder. Websites like jwt.io provide excellent visual tools to decode and inspect JWTs instantly.

Q: Can someone alter the payload of my JWT if they decode it? A: They can alter the payload easily, but because they do not have your server's secret signing key, they cannot generate a valid Signature for the altered payload. When your server receives the altered token, the signature verification will fail, and the token will be rejected.

Q: What is the difference between Base64 and Base64URL? A: Standard Base64 uses + and / and relies on = for padding. Base64URL replaces + with -, / with _, and removes the = padding to ensure the string can be safely used in web URLs.