Use case: General-purpose binary encoding (email, JSON, file transfer)
Character set: A–Z a–z 0–9 + /
Features:
① Every 3 bytes → 4 characters
② Uses = for padding
③ Increases size by ~33%
④ Not suitable for URLs
Example: Hello → SGVsbG8=
Use case: Web URLs, JWT tokens
Character set changes: ① + → - ② / → _
Features: ① URL-safe, suitable for query/path ② Usually removes padding (=)
Use case: TOTP, DNS, security systems
Character set: A–Z 2–7
Features:
① More secure but longer
② Uses only uppercase letters and digits 2–7
③ Suitable for manual input with fewer errors
④ Uses = for padding
Use case: RFC-compatible systems
Character set: 0–9 A–V
Features:
① Closer to hexadecimal style
② More machine-friendly
③ Uses = for padding
Use case: Blockchain (Bitcoin, IPFS)
Character set: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
Features: ① Removes confusing characters like 0, O, I, l, +, / ② No padding ③ Suitable for manual copy/paste input
Use case: HTTP GET parameter transmission
Rules: ① Space → + ② Special characters → %XX
Examples: ① hello world → hello+world ② hello? → hello%3F
| Encoding | Character Set | Padding | URL Safe | Use Case |
|---|---|---|---|---|
| Base64 Std | A–Z a–z 0–9 + / | = | ❌ | General transfer |
| Base64 URL | A–Z a–z 0–9 - _ | ✅ | JWT / Web | |
| Base32 Std | A–Z 2–7 | = | ❌ | TOTP / DNS |
| Base32 HEX | 0–9 A–V | = | ❌ | RFC systems |
| Base58 | 1–9 A–Z a–z (excluding O, o) | ✅ | Blockchain addresses | |
| URL Query | %XX encoding | ✅ | HTTP parameters |