Base64url Encoder / Decoder

What Base64url changes from Base64

Base64url is the URL- and filename-safe alphabet defined in RFC 4648 section 5. It uses the same six-bit grouping as ordinary Base64, but replaces + with - and / with _. Those substitutions avoid characters that have special meanings in URLs, form encoding, paths, shells, and some filenames. The remaining letters and digits keep the same values.

Padding is a separate question from the alphabet. Standard Base64 normally uses trailing equals signs to make the character count a multiple of four. Many Base64url protocols, including common compact token formats, omit padding because the enclosing syntax already reveals the segment length. This page lets the encoder include or remove padding and lets the decoder accept either canonical form.

The input side is text-oriented: Unicode is encoded as UTF-8 before six-bit conversion, and decoded bytes must be valid UTF-8 before display. Base64url can also carry arbitrary binary content, so application code may need byte-level functions when working with signatures, compressed data, keys, or image bytes.

How to use the Base64url converter

1. Choose Encode when starting with text, or Decode when starting with a URL-safe Base64 string.
2. For encoding, match the target protocol’s padding rule. JWT segments are usually unpadded, while another API may require equals signs.
3. Paste the value without spaces. The decoder accepts A-Z, a-z, 0-9, hyphen, underscore, and valid trailing padding only.
4. Check for - and _ when comparing against ordinary Base64. A value that contains + or / belongs to the standard alphabet and is rejected here.
5. Swap direction to verify UTF-8 recovery, then apply any protocol-specific parsing, signature verification, or schema validation separately.

Base64url examples and alphabet differences

Text vectors often look identical to ordinary Base64, so the byte examples deliberately include values that produce slash and plus in the standard alphabet. Padding is shown as a separate policy choice.

Alphabet, padding, and valid lengths

The URL-safe alphabet consists of letters, digits, hyphen, and underscore. Padding may appear only as one or two equals signs at the end. Whitespace is rejected instead of stripped because URL segments and token components are normally contiguous, and silently removing characters can conceal a damaged copy.

An unpadded Base64url value may have a length remainder of zero, two, or three modulo four. A remainder of one cannot represent a whole number of bytes. When padding is supplied, its count must exactly restore a four-character block.

• Use - where ordinary Base64 would use +.
• Use _ where ordinary Base64 would use /.
• Trailing padding is optional for encoding but must be structurally correct when present.
• A plus sign, slash, embedded equals sign, or whitespace produces an error.
• Unused low bits in the final Base64 quantum must be zero for canonical input.

How Base64url converts UTF-8 bytes

The encoder reads three bytes, or twenty-four bits, at a time and divides them into four six-bit values. Each value selects one symbol from the Base64 alphabet. Base64url changes only the symbols at indexes sixty-two and sixty-three. If one or two source bytes remain, zero bits complete the temporary group and one or two equals signs may mark how many output bytes are absent.

For unpadded output, the encoder removes only those trailing equals signs; it does not remove data characters. The decoder calculates how much padding is implied by the length, maps - and _ back to the standard alphabet, reconstructs bytes, and verifies that any unused bits are zero. This is why simply accepting every alphanumeric-looking string can produce ambiguous representations.

After byte reconstruction, this page uses a fatal UTF-8 decoder. A browser’s permissive decoder may substitute U+FFFD for damaged bytes and make a failed conversion look successful. Strict decoding keeps the distinction between a valid Base64url byte sequence and valid Base64url text.

Common Base64url use cases

Base64url belongs inside protocols that need binary or structured data in a compact URL-safe text field. It does not provide confidentiality or authenticity, so security-sensitive protocols add signatures, MACs, encryption, or checksums separately.

Base64url errors and protocol boundaries

The most common failure is feeding ordinary Base64 directly into a Base64url parser. Replacing the alphabet characters may be sufficient at the raw encoding level, but an application must still know whether padding is permitted and what the decoded bytes mean.

A successfully decoded segment is not automatically trustworthy. For example, displaying a JWT payload does not verify its signature, issuer, audience, expiration, or algorithm. Encoding and protocol validation are separate layers.

• A length of one modulo four is impossible and is rejected.
• Padding in the middle or excessive padding is invalid.
• Standard Base64 + and / characters are rejected rather than normalized silently.
• Decoded binary data may not be UTF-8 text.
• Base64url is reversible and should never be described as encryption.

Base64url compared with Base64 and URL encoding

Ordinary Base64 and Base64url represent the same six-bit values with two different symbols. URL percent-encoding solves a different problem: it escapes characters in a URL component and does not convert arbitrary binary data into a compact alphabet.

Hexadecimal is easier to inspect and never needs padding, but it doubles the byte length. Base58 avoids several ambiguous characters but is less standardized for web protocols and uses different arithmetic.