Distinguish a Base64 marker from a parameter
04The special ;base64 suffix has no equals sign. It selects an encoding step for the carried payload.
Separate example: data:text/plain;base64=yes,SGk= has an ordinary metadata parameter. Without a bare ;base64 marker the carried bytes spell SGk=; they do not become Hi.
Source for this drawing: RFC 2397 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A request starts a conversation.
A client asks for a resource. A server sends a response. The method, address, headers, and status explain what that conversation means.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
An equals sign changes the metadata role.
- The optional ;base64 marker appears immediately before the comma. When present, the payload is Base64-encoded data; it is not an extra network protocol.
- Base64 maps bytes into a text alphabet. In the example, SGk= decodes to hexadecimal bytes 48 69, spelling Hi. The padding equals sign is part of the payload, not a metadata parameter delimiter.
- A metadata item base64=yes has a following equals sign, so it is a content-type parameter, not the ;base64 encoding marker. No semantics for that example parameter are defined here.
Base64 is an encoding, not encryption, compression or authentication. RFC2397 uses MIME Base64; URL escaping is also relevant to the URL representation. The bounded model percent-unescapes the payload before its optional strict Base64 step. It accepts standard padded examples and does not claim to reproduce every MIME decoder or current browser tolerance. No data URL is navigated or used as an image/script source in these demonstrations.
Read the RFC section ↗