A Human's Guide to RFC 4648

If you work in software development long enough, you'll eventually be directed to read an "RFC". RFC stands for Request for Comments, and these documents are the foundational blueprints that define how the internet works.

RFC 4648 is the official standard published by the Internet Engineering Task Force (IETF) in 2006. It definitively standardizes Base64, Base32, and Base16 (Hexadecimal) encodings.

Reading RFCs can be dry and overly technical. This guide provides a human-readable summary of the most critical takeaways from RFC 4648.

Why was RFC 4648 created?

Before 2006, Base64 was a bit of the wild west. Different specifications (like MIME in RFC 2045 or Privacy Enhanced Mail in RFC 1421) had slightly different rules for how Base64 should be implemented—especially regarding line lengths and which characters to use for the 62nd and 63rd values.

RFC 4648 was created to consolidate these rules into a single, unified document that all software developers could rely on, regardless of what protocol they were building.

Key Takeaways from the Standard

1. The Standard Alphabet

RFC 4648 strictly defines the standard 64-character alphabet to be used:

• A-Z (Values 0-25)
• a-z (Values 26-51)
• 0-9 (Values 52-61)
• + (Value 62)
• / (Value 63)

It specifically notes that these characters were chosen because they are universally printable and not altered by legacy text-processing systems.

2. The Creation of Base64URL

One of the most important contributions of RFC 4648 (Section 5) is the official definition of the URL and Filename Safe Alphabet, commonly known as Base64URL.

The standard explicitly recognizes that + and / cause major issues when embedded in URLs or file systems. Therefore, it mandates the substitution:

+ becomes - (minus) / becomes _ (underscore)

3. Padding is Mandatory (Mostly)

The standard dictates that padding with the equals sign (=) must be used at the end of the encoded string if the input is not a multiple of 3 bytes.

However, it provides a very critical exception in Section 3.2:"In some circumstances, the use of padding is not required... if the length of the unencoded data is known." This is the exact clause that allows JWTs (JSON Web Tokens) to safely drop the padding characters!

4. Line Feeds and Formatting

Older standards required Base64 strings to be broken into lines of exactly 76 characters, separated by carriage returns and line feeds (CRLF).

RFC 4648 clarifies that unless the specific protocol you are using (like MIME) demands line breaks, you should not add line breaks to Base64 strings. Furthermore, decoders must be written to safely ignore any carriage returns, line feeds, or whitespace they encounter.

What about Base32 and Base16?

While famous for Base64, RFC 4648 also defines:

• Base32: Uses a 32-character alphabet (A-Z and 2-7). It is used when human transcription is required, as it avoids visually similar characters like 1, l, 0, and O.
• Base16: This is simply standard Hexadecimal encoding (0-9, A-F).

If you want to read the official specification in its entirety, you can view the original text document at the IETF Datatracker.