Carry the content inside the URL
01A data URL contains the data itself rather than naming a separate resource to retrieve.
The inline payload supplies bytes 48 69 in hexadecimal, which spell Hi in US-ASCII. This example needs no separate content retrieval; interpretation remains a different decision.
Source for this drawing: RFC 2397 · Read RFC section 2 ↗
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.
The comma separates metadata from carried content.
- The form is data:[media type][;base64],data. The first literal comma separates the description from the payload; later commas can be part of the data.
- A URL is a Uniform Resource Locator. Here data is the scheme name, not an acronym. Inline means the small content is included in the URL itself.
- There are no relative data URL forms. This scheme does not provide a host or a relative path to resolve; applications still decide how to use the carried content.
The diagrams compare a fictional HTTPS reference with data:,Hi. No request is made and no content is executed. A data URL supplies bytes directly, but this does not imply that interpreting arbitrary embedded content can never trigger further behavior. Field widths are schematic; [omitted] is an explanatory placeholder, not literal URL text.
Read the RFC section ↗