Visual RFC.
ALL RFCs / RFC 4648
Read the RFC ↗

RFC 4648 / START HERE

Base encodings, before the details

Base16, Base32, and Base64 encodings

These encodings represent bytes using restricted sets of text characters. They make binary data easier to carry in text-oriented systems.

Start the guide See the 5 chapters ↓

The idea in one picture

  1. Binary bytes need transport

  2. An encoding writes safe characters

  3. A decoder recovers the bytes

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

Some systems cannot safely carry arbitrary bytes as text. Encoding changes the representation; it does not encrypt or hide the data.

A familiar example

An email attachment's bytes can be represented as Base64 text for transport inside a message.

Helpful background

You can start here without reading another RFC. The guide introduces its essential concepts as you go.

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Base64 bit groupsThree input bytes become four six-bit alphabet indices.
  2. Padding and pad bitsA short final group uses zero pad bits and, unless specified otherwise, equals-sign padding.
  3. Base64url alphabetThe URL-safe alphabet changes two symbols without changing the six-bit grouping.
  4. Base32 and Base16Different group sizes create different alphabets and expansion ratios.
  5. Strictness and canonical formA consuming protocol must say when to tolerate non-alphabet characters or line breaks.
Start with chapter one →

This introduction explains RFC 4648 (2006). Read the original RFC ↗