What is the difference between srcdoc="..." and src="data:text/html,..." in an <iframe>?

Question

For example, which is the difference between these:

<iframe srcdoc="<p>Some HTML</p>"></iframe>
<iframe src="data:text/html,<p>Some HTML</p>"></iframe>

Demo

And, in case they are exactly the same, why did HTML5 add srcdoc attribute?

Edit

Maybe I wasn't clear enough. I am not comparing src with srcdoc, but src using text/html data URI with srcdoc.

Then, if the functionality chart is like this

                   |  src attribute       |  srcdoc attribute
 --------------------------------------------------------------------
  URL              |  Yes                 |  No without using src (*)
  HTML content     |  Yes, using data URI |  Yes

why is srcdoc needed?

---

(*) Note:

It seems srcdoc can be used to load a page by URL (Demo), using a subiframe with srcattribute:

<iframe srcdoc="<iframe src='http://microsoft.com'></iframe>"></iframe>

Answer 1

The other answers list some superficial differences, but really miss the mark of the key difference that explains why browsers/spec writers would essentially duplicate something that already exists:

<iframe src="data:...untrusted content" sandbox /> <- Secure in modern browsers, insecure in legacy browsers with no sandbox support

<iframe srcdoc="...untrusted content" sandbox /> <- Secure in modern browsers, secure (though non-functional) in legacy browsers

This new syntax provides content authors a way to protect their users, even when they may be using legacy browsers. Without it, content authors would be reluctant to use the sandbox feature at all, and it would not see use.

Answer 2

iframe with src attribute with HTML Content is cross domain. This is true even with data URLs as mentioned here

data: URLs get a new, empty, security context.

But iframe with srcdoc attribute with HTML Content is not cross domain.

So using the src attribute might cause errors if you try to access/manipulate the iframe from the parent page:

Blocked a frame with origin "..." from accessing a cross-origin frame.

Answer 3

From MDN documentation on the srcdoc attribute :

Inline HTML to embed, overriding the src attribute. If a browser does not support the srcdoc attribute, it will fall back to the URL in the src attribute.

Older MDN documentation on srcdoc says:

The content of the page that the embedded context is to contain. This attribute is expected to be used together with the sandbox and seamless attributes.

So, the srcdoc attribute overrides the content embedded using src attribute.

Demo

(Note: The seamless attribute has since been removed, and another answer describes how sandbox attribute should be "used with the srcdoc attribute"; both attributes were introduced in HTML5; sandbox should be used in case the srcdoc contains untrusted content.

---

Also, what you are saying about the following snippet data:text/html is called data URL and it might have length limitations, so src is limited in what it can show, whereas srcdoc is less limited.

MSDN mentions length limitations:

Data URIs cannot be larger than 32,768 characters.

But other browsers might have different data URL length limits (higher limits) on data URLs themselves (see Chromium might allow 512 URLs), but still not allow URLs to exceed 2MB

Answer 4

As of writing - srcdoc in Chrome (v36) allows the setting and fetching of cookies, whereas the use of src with data URL does not:

Uncaught SecurityError: Failed to read the 'cookie' property from 'Document': Cookies are disabled inside 'data:' URLs

This may or may not be important to you, but rules out the use of data URLs in the application I am building, which is a shame, as of course IE doesn't support srcdoc currently (v11).

Answer 5

Another noticeable difference is that src attributes with data-uri support URI percent-encoding rules while srcdoc doesn't as it supports regular html syntax,

these sources will yield differently:

<iframe srcdoc="<p>hello%20world</p><h1>give%0D%0Ame%0D%0Asome%24</h1>"></iframe>

<iframe src="data:text/html;charset=UTF-8,<p>hello%20datauri<p><h1>give%0D%0A me%0D%0Asome%24</h1>"></iframe>

I also noticed a difference in the parsing of js scripts inside the attributes value( it's probably more than just percentage-encoding ) but didn't figure the rule yet...

Answer 6

Another difference is how links to fragments inside the iframe HTML work. Let's say your HTML content has a link/<a> pointing to a document fragment/hash/id somewhere in the same page, like this:

<a href="#in_src"></a>

<!-- lots of other content, requiring scrolling -->

<p id="in_src"></p>

• If you use the src attribute, (example on jsfiddle, or jsbin) the same link will scroll/jump you to the relevant fragment (as I expected).

• If you use the srcdoc attribute, (example on jsfiddle, or jsbin) a fragment link like the above will try to re-navigate the entire iframe to a whole new page, (based on the parent page's context? I'm not sure, but it's not what I expected)

Maybe this is because of the difference in domains in srcdoc vs src? Maybe the difference in their baseURI values (see more below?). I'm not sure

I tested this on Chrome Version 111.0.5563.149 (Official Build) (64-bit)

EDIT

I wanted to the link to scroll/jump to the document fragment, even with a srcdoc attribute. So in this example I used Javascript to...

• addEventListener() for the click event
• event.preventDefault() (to prevent the anchor's iframe-resetting behavior)
• and use location.hash= '#in_src'; to manually jump to the doc fragment.

Note that the values of e.target.attributes.href.value and e.target.href do not necessarily have the same value (i.e. the value of the fragment ''#in_src'`)

• The attributes.href.value is the literal string value of the href attribute, like '#in_src'
• But the href property of the HTMLAnchorElement API has a "a string [value] containing the whole URL"
  • in the case of srcdoc, the href value is something like 'https://...#i01' (the baseURI value is the parent's URL (iframeWindow.parent.document.baseURI), and maybe that's why clicking the link will navigate the whole iframe)
  • in the case of src using a data URI, the href value is something like 'data:text/html,...#i01, (the baseURI value is the data URI, and will jump to the fragment instead of navigating the hwole page)

Answer 7

In your example the two forms are functionally identical. However, you can use both src and srcdoc attributes, allowing non-HTML5 browsers to use the src version, while HTML5 browsers can use the srcdoc version along with the sandbox and seamless attributes which offer more flexibility in how an iFrame is treated.

Answer 8

srcdoc: The content of the page that the embedded context is to contain. This attribute is expected to be used together with the sandbox and seamless attributes. If a browser supports the srcdoc attribute, it will override the content specified in the src attribute (if present). If a browser does NOT support the srcdoc attribute, it will show the file specified in the src attribute instead (if present).

src: The URL of the page to embed.

Answer 9

The main difference is that the 'src' attribute contains the address of the document you are going to embed in the tag.

On the other hand 'srcdoc'attribute contains the HTML content of the page to show in the inline frame.

the main disadvantage of srcdoc is that it is not supported in all browsers whereas src is compatible with all the browsers.

for detailed explanation please go through the following link: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe