RFC 2397 / START HERE
Inline data URLs, before the details
The data URL scheme carries small content inside a Uniform Resource Locator (URL). The word data is the scheme name, not an acronym.
Instead of pointing to another file to retrieve, it includes the content bytes after a comma, with optional metadata describing the media type and encoding.
The idea in one picture
Inline URL
Carried bytes
Application policy
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Small embedded items sometimes need to travel with the document that refers to them. RFC2397 provides immediate data while leaving interpretation and size limits to the application.
A familiar example
A tiny note can be written as data:,Hi, or an image can carry its bytes as Base64 text. Neither representation authenticates the content or permits an application to ignore its security policy.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Carry the content inside the URLA data URL contains the data itself rather than naming a separate resource to retrieve.→
- Choose the media type and charsetA media type tells the application what kind of content the bytes represent. A charset tells a text decoder how to map bytes to characters.→
- Decode percent escapes as bytesPercent encoding represents one byte with two hexadecimal digits; it is not a Unicode character escape or form-field encoding.→
- Distinguish a Base64 marker from a parameterThe special ;base64 suffix has no equals sign. It selects an encoding step for the carried payload.→
- Bound size and check interpretation policyShort inline data is useful, but valid decoding neither grants permission to interpret a type nor guarantees an application can handle its size.→
This introduction explains RFC 2397 (1998). Read the original RFC ↗