Encoding comparison

Base64 vs Base64URL: What Changes?

Base64URL encodes the same bytes as standard Base64 but replaces + with -, replaces / with _, and commonly omits trailing = padding. The URL-safe alphabet prevents those characters from being reinterpreted inside URLs, filenames, and JWT segments.

6 minute readUpdated August 4, 2026

At a glance

Quick answer

Base64 and Base64URL represent the same binary data with different alphabet characters.
Base64URL uses - and _ instead of + and /, and padding is often omitted.
JWT header and payload segments use Base64URL, not ordinary Base64.
Decoding bytes as text still requires the correct character encoding, usually UTF-8.

Alphabet and padding differences

Both formats convert binary data into groups of printable characters. The only alphabet differences are the characters used for values 62 and 63. Standard Base64 uses + and /, while Base64URL uses - and _.

Standard Base64 normally pads output with one or two = characters so the length is a multiple of four. Base64URL permits padding, but protocols such as JWT usually omit it. A decoder can restore the missing padding after confirming that the remaining length is valid.

Standard Base64 alphabet

A-Z a-z 0-9 + /
Optional ending: = or ==

Base64URL alphabet

A-Z a-z 0-9 - _
Padding is commonly omitted

Why URLs and JWTs use Base64URL

The + character can be interpreted as a space in form-style query strings, / has path meaning, and = is commonly used as a key-value separator. Percent-encoding can protect those characters, but a URL-safe alphabet is easier for protocols that embed encoded values directly.

A JWT has three dot-separated segments. The header and payload are JSON encoded as UTF-8 and then encoded with Base64URL without padding. Decoding those segments reveals their contents, but it does not verify the token signature or establish that the claims are trustworthy.

Convert between the two variants

To convert standard Base64 to Base64URL, replace + with -, replace / with _, and remove trailing = padding when the target protocol requires unpadded output. To decode Base64URL with a standard decoder, reverse the replacements and restore padding until the length is divisible by four.

Reject characters outside the selected alphabet instead of silently ignoring them.
Do not invent padding for a string whose length modulo four is one; that shape cannot represent valid Base64 data.
Validate unused padding bits when canonical encoding matters.

Encoded bytes are not automatically text

Base64 transports bytes. If the original bytes are UTF-8 text, decode them as UTF-8 after Base64 decoding. If the bytes are an image, compressed file, or encrypted payload, forcing them through a text decoder can produce replacement characters or an error.

The reverse also matters: encode text to UTF-8 bytes before creating Base64. Browser functions designed around Latin-1 strings can corrupt emoji and non-Latin characters unless the text is converted to bytes first.

Choose the variant required by the protocol

Use standard Base64 for formats that explicitly require it, such as many MIME and data serialization contexts. Use Base64URL for JWT segments and values that must travel unescaped in URLs or filenames. Do not switch alphabets merely for appearance; interoperability depends on matching the receiving specification.