Standard Base64 vs. Base64URL

For a Base64 URL-safe variant (often called base64url), the standard is defined in RFC 4648 §5 (“Base 64 Encoding with URL and Filename Safe Alphabet”).

Standard Base64 vs. Base64URL

Standard Base64 (RFC 4648 §4):
- Alphabet: `A–Z a–z 0–9 + /`
- Padding: `=` (optional in some contexts, but usually present)
- Not URL-safe: `+ / =` often require percent-encoding (`%2B %2F %3D`) when embedded in URLs.

Base64URL (the URL-safe variant):
- Alphabet: `A–Z a–z 0–9 - _`
  - `+` → `-` (hyphen-minus)
  - `/` → `_` (underscore)
- Padding: Usually omitted entirely for URL/query-string usage (length must be known or padded implicitly via context), or kept as `=` if needed (but then often percent-encoded).
- Goal: Produce strings that are safe to embed in URLs, path segments, query parameters, headers, etc., without extra escaping.

Full Alphabet Mapping (0–63)

| Value | Char | Value | Char | Value | Char | Value | Char |
|-------|------|-------|------|-------|------|-------|------|
| 0     | A    | 16    | Q    | 32    | g    | 48    | w    |
| 1     | B    | 17    | R    | 33    | h    | 49    | x    |
| 2     | C    | 18    | S    | 34    | i    | 50    | y    |
| 3     | D    | 19    | T    | 35    | j    | 51    | z    |
| 4     | E    | 20    | U    | 36    | k    | 52    | 0    |
| 5     | F    | 21    | V    | 37    | l    | 53    | 1    |
| 6     | G    | 22    | W    | 38    | m    | 54    | 2    |
| 7     | H    | 23    | X    | 39    | n    | 55    | 3    |
| 8     | I    | 24    | Y    | 40    | o    | 56    | 4    |
| 9     | J    | 25    | Z    | 41    | p    | 57    | 5    |
| 10    | K    | 26    | a    | 42    | q    | 58    | 6    |
| 11    | L    | 27    | b    | 43    | r    | 59    | 7    |
| 12    | M    | 28    | c    | 44    | s    | 60    | 8    |
| 13    | N    | 29    | d    | 45    | t    | 61    | 9    |
| 14    | O    | 30    | e    | 46    | u    | 62    | -    |
| 15    | P    | 31    | f    | 47    | v    | 63    | _    |

Common Usage Rules

- No padding (`=`) is the most popular choice for URLs → trim trailing `=` after encoding.
- If padding is kept, `%3D` appears in the URL (less clean).
- Decoding must handle both padded and unpadded input (most libraries do).
- The resulting string is safe in:
  - URL path segments
  - Query parameters
  - Fragment identifiers
  - HTTP headers (most cases)
  - JSON strings (no escaping needed)

Python Example (using built-in `base64`)

```python
import base64

data = b"Hello, world! This is a test."

# Standard base64 (not URL-safe)
standard = base64.b64encode(data).decode('ascii')
print(standard)          # SGVsbG8sIHdvcmxkISBUaGlzIGlzIGEgdGVzdC4=

# Base64URL – no padding
urlsafe = base64.urlsafe_b64encode(data).decode('ascii').rstrip('=')
print(urlsafe)           # SGVsbG8sIHdvcmxkISBUaGlzIGlzIGEgdGVzdC4

# Decode back (urlsafe_b64decode handles missing padding automatically)
decoded = base64.urlsafe_b64decode(urlsafe + '==='[: (4 - len(urlsafe) % 4) % 4])
print(decoded)           # b'Hello, world! This is a test.'
```

Other Languages

- **JavaScript** (Web Crypto / Buffer): `btoa()` is standard; for url-safe use libraries like `js-base64` or manual replace `+/=` → `-_` + trim `=`.
- **Go**: `encoding/base64.URLEncoding`
- **Java**: `java.util.Base64.getUrlEncoder().withoutPadding()`
- **Rust**: `base64::engine::general_purpose::URL_SAFE_NO_PAD`

This is the de-facto standard for compact, URL-safe binary-to-text encoding (used in JWTs, data URIs, OAuth tokens, etc.). If you're looking for something higher-radix like a true **Base72 URL-safe** variant (72 chars), no official standard exists — custom alphabets are sometimes proposed (e.g., extending base64url with extra safe chars like `. ~`), but they lose interoperability.

Let me know if you want a custom Base72 proposal built on top of base64url principles, or code for a specific language!