Skip to main content

RFC 4648 - The Base16, Base32, and Base64 Data Encodings

  • Status: Proposed Standard
  • Published: October 2006
  • Stream: IETF
  • Obsoletes: RFC3548
  • Errata: No Errata

Abstract​

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.

Status of This Memo​

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2006).

Table of Contents​

Main Sections​

Why Base Encoding Matters​

Base encoding is fundamental to internet data transmission. It converts binary data into text format, enabling transmission and storage in text-only environments.

Core Use Cases​

EncodingPrimary PurposeTypical Applications
Base64General binary encodingMIME email attachments, JWT tokens, Data URIs
Base64URLURL-safe encodingJWT, OAuth tokens, URL parameters
Base32Human-readable encodingTOTP keys, Crockford encoding
Base16Hexadecimal encodingHash display, debug output

Base64 Quick Reference​

Standard Base64 Encoding​

Character Set: A-Z, a-z, 0-9, +, /
Padding Character: =
Output Length: Input bytes × 4/3 (rounded up to multiple of 4)

Example:
Input: "Hello"
Output: "SGVsbG8="

Encoding Process:
H     e     l     l     o
01001000 01100101 01101100 01101100 01101111
↓ Group by 6 bits
010010 000110 010101 101100 011011 000110 1111
↓ Look up table
S      G      V      s      b      G      8=

Base64URL Encoding (RFC 4648 §5)​

Character Set: A-Z, a-z, 0-9, -, _
Padding Character: = (typically omitted)

Differences from Standard Base64:
+ → -
/ → _

Usage: JWT, OAuth tokens, URL parameters

Base Encoding Reference Tables​

Base64 Standard Character Table​

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    /

Padding Character: =

Base32 Standard Character Table​

Value Char  Value Char
  0    A     16    Q
  1    B     17    R
  2    C     18    S
  3    D     19    T
  4    E     20    U
  5    F     21    V
  6    G     22    W
  7    H     23    X
  8    I     24    Y
  9    J     25    Z
 10    K     26    2
 11    L     27    3
 12    M     28    4
 13    N     29    5
 14    O     30    6
 15    P     31    7

Padding Character: =

Real-World Applications​

JWT (JSON Web Token)​

JWT Structure:
header.payload.signature

Each part is Base64URL encoded:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Data URI​

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA..." />

MIME Email Attachments​

Content-Type: application/pdf
Content-Transfer-Encoding: base64

JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9n...
  • RFC 2045 - MIME Part One (Defines Base64 for MIME)
  • RFC 3548 - Base Encodings (Obsoleted by RFC 4648)
  • RFC 7515 - JSON Web Signature (Uses Base64URL)
  • RFC 7519 - JSON Web Token (Uses Base64URL)