Base64 vs base64url: what's the difference?

Base64 and base64url look almost identical, and most of the time they are. The difference comes down to two characters and the padding, but those small differences decide whether a string survives inside a URL. Here is what changes and when it matters.

They share the same alphabet, mostly

Both encodings represent binary data using 64 printable characters. The first 62 are the same in both: A-Z, a-z, and 0-9. The difference is the final two characters and how padding is handled.

	Standard Base64	base64url
Character 63	+	-
Character 64	/	_
Padding	=	usually omitted
Safe in URLs	No	Yes

That is the whole difference. Everything else about how the data is grouped into characters is the same.

Why the difference exists

Standard Base64 was designed for contexts like email, where +, /, and = are harmless. Inside a URL, those characters are not harmless:

• / is a path separator.
• + is often interpreted as a space.
• = is reserved and is also used in query strings.

So if you drop a standard Base64 string into a URL or a filename, it can be corrupted or rejected. base64url fixes this by swapping + for - and / for _, and by usually dropping the = padding, which is also reserved in URLs.

When to use which

• Use standard Base64 for data URIs, email attachments, and anywhere the

output is not placed directly in a URL or filename.

• Use base64url when the value goes into a URL path, a query parameter, a

filename, or an HTTP header. This is why JSON Web Tokens use it. If you want to read one, see how to read a JWT.

If you only need to put a standard Base64 value into a URL occasionally, you can also URL-encode it instead, though that makes the string longer and harder to read. base64url is the cleaner choice when you control the encoding.

Converting between them

The two are easy to translate. To go from base64url to standard Base64, replace - with + and _ with /, then add = padding until the length is a multiple of four. To go the other way, do the reverse and strip the padding. Most libraries offer a base64url mode so you rarely have to do this by hand.

A quick gotcha

If a base64url string fails to decode, the usual cause is the missing padding. Add = characters back until the length is a multiple of four, or use a decoder that handles base64url directly. Remember too that this is encoding, not encryption: a base64url value hides nothing. The encoding vs encryption vs hashing guide explains why that matters.

Key takeaways

• Base64 and base64url share the same first 62 characters and differ only in the

last two plus padding.

• Standard Base64 uses + and /; base64url uses - and _ and usually drops

the = padding.

• Use base64url anywhere the value goes into a URL, filename, or header, which is

why JWTs use it.

• Converting between the two is a simple character swap plus padding adjustment.
• Neither variant provides any secrecy. Both are encoding, not encryption.