About this specification

This specification is like no other — it has been processed with you, the humble web developer, in mind.

The focus of this specification is readability and ease of access. Unlike the full HTML Standard, this "developer's edition" removes information that only browser vendors need know. It is automatically produced from the full specification by our build tooling, and thus always in sync with the latest developments in HTML.

To read about its conception, construction, and future, read the original press release, and the blog post about its relaunch.

Finally, feel free to contribute on GitHub to make this edition better for everyone!

      1. 4.8.5 The iframe element
      2. 4.8.6 The embed element
      3. 4.8.7 The object element
      4. 4.8.8 The param element

4.8.5 The iframe element

Categories:
Flow content.
Phrasing content.
Embedded content.
Interactive content.
Palpable content.
Contexts in which this element can be used:
Where embedded content is expected.
Content model:
Nothing.
Tag omission in text/html:
Neither tag is omissible.
Content attributes:
Global attributes
src — Address of the resource
srcdoc — A document to render in the iframe
name — Name of nested browsing context
sandbox — Security rules for nested content
allowfullscreen — Whether to allow the iframe's contents to use requestFullscreen()
allowpaymentrequest — Whether the iframe's contents are allowed to use the PaymentRequest interface to make payment requests
allowusermedia — Whether to allow the iframe's contents to use getUserMedia()
width — Horizontal dimension
height — Vertical dimension
referrerpolicy — Referrer policy for fetches initiated by the element
DOM interface:
Uses HTMLIFrameElement.

The iframe element represents a nested browsing context.

The src attribute gives the URL of a page that the nested browsing context is to contain. The attribute, if present, must be a valid non-empty URL potentially surrounded by spaces. If the itemprop attribute is specified on an iframe element, then the src attribute must also be specified.

The srcdoc attribute gives the content of the page that the nested browsing context is to contain. The value of the attribute is the source of an iframe srcdoc document.

The srcdoc attribute, if present, must have a value using the HTML syntax that consists of the following syntactic components, in the given order:

  1. Any number of comments and ASCII whitespace.
  2. Optionally, a DOCTYPE.
  3. Any number of comments and ASCII whitespace.
  4. The document element, in the form of an html element.
  5. Any number of comments and ASCII whitespace.

The above requirements apply in XML documents as well.

Here a blog uses the srcdoc attribute in conjunction with the sandbox attribute described below to provide users of user agents that support this feature with an extra layer of protection from script injection in the blog post comments:

<article>
 <h1>I got my own magazine!</h1>
 <p>After much effort, I've finally found a publisher, and so now I
 have my own magazine! Isn't that awesome?! The first issue will come
 out in September, and we have articles about getting food, and about
 getting in boxes, it's going to be great!</p>
 <footer>
  <p>Written by <a href="/users/cap">cap</a>, 1 hour ago.
 </footer>
 <article>
  <footer> Thirteen minutes ago, <a href="/users/ch">ch</a> wrote: </footer>
  <iframe sandbox srcdoc="<p>did you get a cover picture yet?"></iframe>
 </article>
 <article>
  <footer> Nine minutes ago, <a href="/users/cap">cap</a> wrote: </footer>
  <iframe sandbox srcdoc="<p>Yeah, you can see it <a href=&quot;/gallery?mode=cover&amp;amp;page=1&quot;>in my gallery</a>."></iframe>
 </article>
 <article>
  <footer> Five minutes ago, <a href="/users/ch">ch</a> wrote: </footer>
  <iframe sandbox srcdoc="<p>hey that's earl's table.
<p>you should get earl&amp;amp;me on the next cover."></iframe>
 </article>

Notice the way that quotes have to be escaped (otherwise the srcdoc attribute would end prematurely), and the way raw ampersands (e.g. in URLs or in prose) mentioned in the sandboxed content have to be doubly escaped — once so that the ampersand is preserved when originally parsing the srcdoc attribute, and once more to prevent the ampersand from being misinterpreted when parsing the sandboxed content.

Furthermore, notice that since the DOCTYPE is optional in iframe srcdoc documents, and the html, head, and body elements have optional start and end tags, and the title element is also optional in iframe srcdoc documents, the markup in a srcdoc attribute can be relatively succinct despite representing an entire document, since only the contents of the body element need appear literally in the syntax. The other elements are still present, but only by implication.

In the HTML syntax, authors need only remember to use U+0022 QUOTATION MARK characters (") to wrap the attribute contents and then to escape all U+0022 QUOTATION MARK (") and U+0026 AMPERSAND (&) characters, and to specify the sandbox attribute, to ensure safe embedding of content.

In XML the U+003C LESS-THAN SIGN character (<) needs to be escaped as well. In order to prevent attribute-value normalization, some of XML's whitespace characters — specifically U+0009 CHARACTER TABULATION (tab), U+000A LINE FEED (LF), and U+000D CARRIAGE RETURN (CR) — also need to be escaped. [XML]

If the src attribute and the srcdoc attribute are both specified together, the srcdoc attribute takes priority. This allows authors to provide a fallback URL for legacy user agents that do not support the srcdoc attribute.

If, when the element is created, the srcdoc attribute is not set, and the src attribute is either also not set or set but its value cannot be parsed, the browsing context will remain at the initial about:blank page.

If the user navigates away from this page, the iframe's corresponding WindowProxy object will proxy new Window objects for new Document objects, but the src attribute will not change.

The name attribute, if present, must be a valid browsing context name. The given value is used to name the nested browsing context.

The sandbox attribute, when specified, enables a set of extra restrictions on any content hosted by the iframe. Its value must be an unordered set of unique space-separated tokens that are ASCII case-insensitive. The allowed values are allow-forms, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-popups, allow-popups-to-escape-sandbox, allow-presentation, allow-same-origin, allow-scripts, allow-top-navigation, and allow-top-navigation-by-user-activation.

When the attribute is set, the content is treated as being from a unique origin, forms, scripts, and various potentially annoying APIs are disabled, links are prevented from targeting other browsing contexts, and plugins are secured. The allow-same-origin keyword causes the content to be treated as being from its real origin instead of forcing it into a unique origin; the allow-top-navigation keyword allows the content to navigate its top-level browsing context; the allow-top-navigation-by-user-activation keyword behaves similarly but only allows such navigation when triggered by user activation; and the allow-forms, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-popups, allow-presentation, allow-scripts, and allow-popups-to-escape-sandbox keywords re-enable forms, modal dialogs, screen orientation lock, the pointer lock API, popups, the presentation API, scripts, and the creation of unsandboxed auxiliary browsing contexts respectively. [POINTERLOCK] [SCREENORIENTATION] [PRESENTATION]

The allow-top-navigation and allow-top-navigation-by-user-activation keywords must not both be specified, as doing so is redundant; only allow-top-navigation will have an effect in such non-conformant markup.

Setting both the allow-scripts and allow-same-origin keywords together when the embedded page has the same origin as the page containing the iframe allows the embedded page to simply remove the sandbox attribute and then reload itself, effectively breaking out of the sandbox altogether.

These flags only take effect when the nested browsing context of the iframe is navigated. Removing them, or removing the entire sandbox attribute, has no effect on an already-loaded page.

Potentially hostile files should not be served from the same server as the file containing the iframe element. Sandboxing hostile content is of minimal help if an attacker can convince the user to just visit the hostile content directly, rather than in the iframe. To limit the damage that can be caused by hostile HTML content, it should be served from a separate dedicated domain. Using a different domain ensures that scripts in the files are unable to attack the site, even if the user is tricked into visiting those pages directly, without the protection of the sandbox attribute.

In this example, some completely-unknown, potentially hostile, user-provided HTML content is embedded in a page. Because it is served from a separate domain, it is affected by all the normal cross-site restrictions. In addition, the embedded page has scripting disabled, plugins disabled, forms disabled, and it cannot navigate any frames or windows other than itself (or any frames or windows it itself embeds).

<p>We're not scared of you! Here is your content, unedited:</p>
<iframe sandbox src="https://usercontent.example.net/getusercontent.cgi?id=12193"></iframe>

It is important to use a separate domain so that if the attacker convinces the user to visit that page directly, the page doesn't run in the context of the site's origin, which would make the user vulnerable to any attack found in the page.

In this example, a gadget from another site is embedded. The gadget has scripting and forms enabled, and the origin sandbox restrictions are lifted, allowing the gadget to communicate with its originating server. The sandbox is still useful, however, as it disables plugins and popups, thus reducing the risk of the user being exposed to malware and other annoyances.

<iframe sandbox="allow-same-origin allow-forms allow-scripts"
        src="https://maps.example.com/embedded.html"></iframe>

Suppose a file A contained the following fragment:

<iframe sandbox="allow-same-origin allow-forms" src=B></iframe>

Suppose that file B contained an iframe also:

<iframe sandbox="allow-scripts" src=C></iframe>

Further, suppose that file C contained a link:

<a href=D>Link</a>

For this example, suppose all the files were served as text/html.

Page C in this scenario has all the sandboxing flags set. Scripts are disabled, because the iframe in A has scripts disabled, and this overrides the allow-scripts keyword set on the iframe in B. Forms are also disabled, because the inner iframe (in B) does not have the allow-forms keyword set.

Suppose now that a script in A removes all the sandbox attributes in A and B. This would change nothing immediately. If the user clicked the link in C, loading page D into the iframe in B, page D would now act as if the iframe in B had the allow-same-origin and allow-forms keywords set, because that was the state of the nested browsing context in the iframe in A when page B was loaded.

Generally speaking, dynamically removing or changing the sandbox attribute is ill-advised, because it can make it quite hard to reason about what will be allowed and what will not.

The allowfullscreen attribute is a boolean attribute. When specified, it indicates that Document objects in the iframe element's browsing context are to be allowed to use requestFullscreen() (if it's not blocked for other reasons, e.g. there is another ancestor iframe without this attribute set).

Here, an iframe is used to embed a player from a video site. The allowfullscreen attribute is needed to enable the player to show its video fullscreen.

<article>
 <header>
  <p><img src="/usericons/1627591962735"> <b>Fred Flintstone</b></p>
  <p><a href="/posts/3095182851" rel=bookmark>12:44</a> — <a href="#acl-3095182851">Private Post</a></p>
 </header>
 <main>
  <p>Check out my new ride!</p>
  <iframe src="https://video.example.com/embed?id=92469812" allowfullscreen></iframe>
 </main>
</article>

The allowpaymentrequest attribute is a boolean attribute. When specified, it indicates that Document objects in the iframe element's browsing context are to be allowed to use the PaymentRequest interface to make payment requests.

The allowusermedia attribute is a boolean attribute. When specified, it indicates that Document objects in the iframe element's browsing context are to be allowed to use getUserMedia() (if it's not blocked for other reasons, e.g. there is another ancestor iframe without this attribute set).

The iframe element supports dimension attributes for cases where the embedded content has specific dimensions (e.g. ad units have well-defined dimensions).

An iframe element never has fallback content, as it will always create a nested browsing context, regardless of whether the specified initial contents are successfully used.

The referrerpolicy attribute is a referrer policy attribute. Its purpose is to set the referrer policy used when processing the iframe attributes. [REFERRERPOLICY]

Descendants of iframe elements represent nothing. (In legacy user agents that do not support iframe elements, the contents would be parsed as markup that could act as fallback content.)

The HTML parser treats markup inside iframe elements as text.

Here is an example of a page using an iframe to include advertising from an advertising broker:

<iframe src="https://ads.example.com/?customerid=923513721&amp;format=banner"
        width="468" height="60"></iframe>

4.8.6 The embed element

Categories:
Flow content.
Phrasing content.
Embedded content.
Interactive content.
Palpable content.
Contexts in which this element can be used:
Where embedded content is expected.
Content model:
Nothing.
Tag omission in text/html:
No end tag.
Content attributes:
Global attributes
src — Address of the resource
type — Type of embedded resource
width — Horizontal dimension
height — Vertical dimension
Any other attribute that has no namespace (see prose).
DOM interface:
Uses HTMLEmbedElement.

The embed element provides an integration point for an external (typically non-HTML) application or interactive content.

The src attribute gives the URL of the resource being embedded. The attribute, if present, must contain a valid non-empty URL potentially surrounded by spaces.

If the itemprop attribute is specified on an embed element, then the src attribute must also be specified.

The type attribute, if present, gives the MIME type by which the plugin to instantiate is selected. The value must be a valid MIME type. If both the type attribute and the src attribute are present, then the type attribute must specify the same type as the explicit Content-Type metadata of the resource given by the src attribute.

Any namespace-less attribute other than name, align, hspace, and vspace may be specified on the embed element, so long as its name is XML-compatible and contains no ASCII upper alphas. These attributes are then passed as parameters to the plugin.

All attributes in HTML documents get lowercased automatically, so the restriction on uppercase letters doesn't affect such documents.

The four exceptions are to exclude legacy attributes that have side-effects beyond just sending parameters to the plugin.

The embed element supports dimension attributes.

Here's a way to embed a resource that requires a proprietary plugin, like Flash:

<embed src="catgame.swf">

If the user does not have the plugin (for example if the plugin vendor doesn't support the user's platform), then the user will be unable to use the resource.

To pass the plugin a parameter "quality" with the value "high", an attribute can be specified:

<embed src="catgame.swf" quality="high">

This would be equivalent to the following, when using an object element instead:

<object data="catgame.swf">
 <param name="quality" value="high">
</object>

4.8.7 The object element

Categories:
Flow content.
Phrasing content.
Embedded content.
If the element has a usemap attribute: Interactive content.
Listed and submittable form-associated element.
Palpable content.
Contexts in which this element can be used:
Where embedded content is expected.
Content model:
Zero or more param elements, then, transparent.
Tag omission in text/html:
Neither tag is omissible.
Content attributes:
Global attributes
data — Address of the resource
type — Type of embedded resource
typemustmatch — Whether the type attribute and the Content-Type value need to match for the resource to be used
name — Name of nested browsing context
usemap — Name of image map to use
form — Associates the control with a form element
width — Horizontal dimension
height — Vertical dimension
DOM interface:
Uses HTMLObjectElement.

The object element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin.

The data attribute, if present, specifies the URL of the resource. If present, the attribute must be a valid non-empty URL potentially surrounded by spaces.

Authors who reference resources from other origins that they do not trust are urged to use the typemustmatch attribute defined below. Without that attribute, it is possible in certain cases for an attacker on the remote host to use the plugin mechanism to run arbitrary scripts, even if the author has used features such as the Flash "allowScriptAccess" parameter.

The type attribute, if present, specifies the type of the resource. If present, the attribute must be a valid MIME type.

At least one of either the data attribute or the type attribute must be present.

If the itemprop attribute is specified on an object element, then the data attribute must also be specified.

The typemustmatch attribute is a boolean attribute whose presence indicates that the resource specified by the data attribute is only to be used if the value of the type attribute and the Content-Type of the aforementioned resource match.

The typemustmatch attribute must not be specified unless both the data attribute and the type attribute are present.

The name attribute, if present, must be a valid browsing context name. The given value is used to name the nested browsing context, if applicable.

The usemap attribute, if present while the object element represents an image, can indicate that the object has an associated image map.

The form attribute is used to explicitly associate the object element with its form owner.

The object element supports dimension attributes.

In this example, an HTML page is embedded in another using the object element.

<figure>
 <object data="clock.html"></object>
 <figcaption>My HTML Clock</figcaption>
</figure>

The following example shows how a plugin can be used in HTML (in this case the Flash plugin, to show a video file). Fallback is provided for users who do not have Flash enabled, in this case using the video element to show the video for those using user agents that support video, and finally providing a link to the video for those who have neither Flash nor a video-capable browser.

<p>Look at my video:
 <object type="application/x-shockwave-flash">
  <param name=movie value="https://video.example.com/library/watch.swf">
  <param name=allowfullscreen value=true>
  <param name=flashvars value="https://video.example.com/vids/315981">
  <video controls src="https://video.example.com/vids/315981">
   <a href="https://video.example.com/vids/315981">View video</a>.
  </video>
 </object>
</p>

4.8.8 The param element

Categories:
None.
Contexts in which this element can be used:
As a child of an object element, before any flow content.
Content model:
Nothing.
Tag omission in text/html:
No end tag.
Content attributes:
Global attributes
name — Name of parameter
value — Value of parameter
DOM interface:
Uses HTMLParamElement.

The param element defines parameters for plugins invoked by object elements. It does not represent anything on its own.

The name attribute gives the name of the parameter.

The value attribute gives the value of the parameter.

Both attributes must be present. They may have any value.

The following example shows how the param element can be used to pass a parameter to a plugin, in this case the O3D plugin.

<!DOCTYPE HTML>
<html lang="en">
  <head>
   <title>O3D Utah Teapot</title>
  </head>
  <body>
   <p>
    <object type="application/vnd.o3d.auto">
     <param name="o3d_features" value="FloatingPointTextures">
     <img src="o3d-teapot.png"
          title="3D Utah Teapot illustration rendered using O3D."
          alt="When O3D renders the Utah Teapot, it appears as a squat
          teapot with a shiny metallic finish on which the
          surroundings are reflected, with a faint shadow caused by
          the lighting.">
     <p>To see the teapot actually rendered by O3D on your
     computer, please download and install the <a
     href="http://code.google.com/apis/o3d/docs/gettingstarted.html#install">O3D plugin</a>.</p>
    </object>
    <script src="o3d-teapot.js"></script>
   </p>
  </body>
</html>