Visual RFC.
ALL RFCs / RFC 7617
Read the RFC ↗
RFC 7617 / HTTP BASIC AUTHENTICATION

From user and password to Base64

02

Basic serializes a user-id, a colon separator and a password, then encodes their bytes as Base64 text.

DIAGRAMRead RFC section 2 ↗
RFC 7617 · § 2EXAMPLE
3 / 3
From user and password to Base64The user-id Aladdin and password open sesame are joined by the first colon. Their ASCII-compatible bytes are then Base64 encoded into the exact RFC Authorization example. A separate invalid user-id Al:addin stops at the format gate; a password colon is permitted. Base64 remains reversible.A delimiter, bytes, then Base64RFC example · schematic field widthsuser-idAladdin:passwordopen sesameencode bytesBase64(Aladdin:open sesame)QWxhZGRpbjpvcGVuIHNlc2FtZQ==Authorization: Basic <that value>Decode Base64 → the password is recoverableNo CTL characters in user-id or password (MUST NOT)
03
Write the Authorization field.

Base64 of the 19 bytes is QWxhZGRpbjpvcGVuIHNlc2FtZQ==. Prefix it with Basic in Authorization. Decoding recovers the password; this is not secrecy.

Source for this drawing: RFC 7617 · Read RFC section 2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 9110 HTTP RFC 4648 Base encodings RFC 8446 TLS 1.3

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Octet
An eight-bit byte.
Base64
A reversible representation of bytes using an ASCII alphabet.
token68
HTTP credential syntax carrying the one encoded Basic value.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Construct user-pass as user-id + one colon + password, convert to octets, then use the standard Base64 alphabet from RFC 4648 §4.

  • Construct user-pass as user-id + one colon + password, convert to octets, then use the standard Base64 alphabet from RFC 4648 §4.
  • A user-id containing a colon is invalid. The first colon separates the user-id; any later colons are part of the password.
  • The user-id and password MUST NOT contain control characters (CTL as referenced by §2). This is separate from choosing an encoding.
  • The default character encoding is unspecified but must be compatible with US-ASCII. Base64 is reversible encoding; it provides no encryption or password hashing.
DETAILS

The worked example Aladdin / open sesame is from §2, with ASCII-compatible bytes 41 6C 61 64 64 69 6E 3A 6F 70 65 6E 20 73 65 73 61 6D 65. All credentials in this guide are public fictional examples. A colon in a password is permitted; a colon in the user-id cannot be disambiguated by escaping it in Basic.

Read the RFC section ↗

All chapters in RFC 7617

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗