Base64 vs. Base64url: Why Encoded Text Breaks in URLs and JWTs

If a Base64 value works in one place but fails after it is put in a URL, query parameter, or JWT-like token, the issue is often the alphabet or the padding—not the underlying data. Standard Base64 and Base64url encode the same kinds of bytes, but they use different characters for two positions, and Base64url handles padding differently.

This guide answers a practical question: when should you use standard Base64, Base64url, or ordinary percent-encoding for a URL?

Base64 is an encoding, not encryption

Base64 converts binary data into text characters. It is useful when bytes need to travel through a text-oriented format, but it does not hide the contents. Anyone who has the encoded text can decode it; do not put secrets in Base64 and assume they are protected.

RFC 4648 defines the standard Base64 alphabet as uppercase and lowercase letters, digits, +, and /, with = used for padding when needed. 1

For example, the byte sequence for Hello has the standard Base64 representation SGVsbG8=. The final = is padding that makes the encoded text a multiple of four characters.

Why ordinary Base64 can be awkward in a URL

The characters +, /, and = are legal Base64 characters, but URL contexts can assign special meaning to them. A slash may look like a path separator, and form-style query parsing can interpret a plus sign as a space. This does not mean Base64 is invalid; it means a value must be handled according to the rules of the container that carries it.

There are two different fixes, and they solve different problems:

• Percent-encode a standard Base64 value when an existing protocol expects standard Base64. Encode it as a URL component rather than concatenating raw text into a URL.
• Use Base64url when the protocol or field specifies the URL-safe variant. Do not silently substitute it where a receiver requires standard Base64.

URL percent-encoding represents bytes in a URL component with % followed by hexadecimal digits; the URL Standard defines percent-encode sets for the different URL components. 2

What Base64url changes

RFC 4648 defines a URL- and filename-safe Base64 variant. It replaces + with - and / with _. The specification notes that the pad character = is often omitted in URL-safe uses when the data length is known implicitly, but whether padding may be omitted is a protocol decision. 3

The practical mapping is small:

Standard Base64	Base64url
+	-
/	_
Padding commonly uses =	Padding may be omitted only when the receiving protocol allows it

Do not solve a decoding error by blindly replacing characters or stripping every trailing =. First identify the format required by the sender and receiver. A permissive decoder may accept several spellings, while a strict API may not.

Why JWT-style compact strings use Base64url

JSON Web Signature compact serialization represents its protected header, payload, and signature as dot-separated Base64url values. RFC 7515 specifies Base64url encoding without padding for those parts. 4

That gives a useful debugging rule: if you are inspecting the three dot-separated parts of a JWT-style compact string, expect Base64url rather than ordinary padded Base64. Decode the header or payload only to examine the data; decoding does not verify a signature, prove that a token is current, or authorize a request. Verification must use the expected algorithm, key, and application validation rules.

Also keep the token whole when moving it between systems. Re-encoding a decoded JSON object can change whitespace, member ordering, or other bytes, so it does not recreate the original signed input.

A safe troubleshooting workflow

When an encoded value fails, work from the contract rather than guessing:

1. Preserve the original value and note where it came from: a file, HTTP header, JSON field, query parameter, path, or compact token.
2. Check the protocol documentation for the required variant, character set, and padding rule.
3. If the value is going into a URL component, use a URL-component encoder for that boundary; do not treat Base64url as a universal substitute for URL encoding.
4. Decode only with the variant the protocol calls for, then compare the resulting bytes or text with the expected value.
5. If the data is security-sensitive, keep it out of logs, screenshots, public URLs, and third-party tools unless you are authorized to expose it.

yukt.tools lists Base64 and URL-encoding utilities among its online tools. They can help make a sample value readable during a controlled troubleshooting step, but the receiving protocol remains the authority on which representation it accepts.

Frequently asked questions

Is Base64url the same as URL encoding?

No. Base64url is a variant of Base64 with - and _ in place of + and /. URL percent-encoding is a way to represent bytes inside a URL component. A protocol can require either, both at different boundaries, or neither. 3 2

Can I remove = from any Base64 value?

Not safely as a general rule. RFC 4648 standard Base64 uses padding unless the referring specification says otherwise. Base64url allows a protocol to omit padding when the length is known implicitly; JWT compact serialization is one protocol that requires unpadded Base64url. 1 3 4

Can I decode a JWT to verify it is trustworthy?

No. Decoding exposes the encoded header and payload; it does not validate the signature or the claims. Verify the compact serialization with the expected key and algorithm, then apply the application's issuer, audience, time, and authorization checks as appropriate. 4

Sources and research

1. RFC 4648: The Base16, Base32, and Base64 Data Encodings — IETF specification for standard Base64 and padding, accessed 2026-09-27.
2. URL Standard: Percent-encode — WHATWG URL processing specification, accessed 2026-09-27.
3. RFC 4648, section 5: Base 64 Encoding with URL and Filename Safe Alphabet — IETF specification for Base64url, accessed 2026-09-27.
4. RFC 7515, section 3.1: JWS Compact Serialization — IETF specification for unpadded Base64url in compact JWS, accessed 2026-09-27.