Edition for Web Developers — Last Updated 16 January 2024
iframe
elementSupport in all current engines.
src
— Address of the resource
srcdoc
— A document to render in the iframe
name
— Name of content navigable
sandbox
— Security rules for nested content
allow
— Permissions policy to be applied to the iframe
's contents
allowfullscreen
— Whether to allow the iframe
's contents to use requestFullscreen()
width
— Horizontal dimension
height
— Vertical dimension
referrerpolicy
— Referrer policy for fetches initiated by the element
loading
— Used when determining loading deferral
HTMLIFrameElement
.The iframe
element represents its content navigable.
The src
attribute
gives the URL of a page that the element's content navigable 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.
Support in all current engines.
The srcdoc
attribute gives the content of the page that the element's content navigable is to
contain. The value of the attribute is used to construct an iframe
srcdoc
document, which is a Document
whose
URL matches about:srcdoc
.
The srcdoc
attribute, if present, must have a value
using the HTML syntax that consists of the following syntactic components, in the
given order:
html
element.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="/gallery?mode=cover&amp;page=1">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;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+0026
AMPERSAND (&) and U+0022 QUOTATION MARK (") characters, and to specify the sandbox
attribute, to ensure safe embedding of content. (And
remember to escape ampersands before quotation marks, to ensure quotation marks become "
and not &quot;.)
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 element's content
navigable will remain at the initial
about:blank
Document
.
If the user navigates away from this page, the
iframe
's content navigable's active
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 navigable target name. The given value is
used to name the element's content navigable if present when that is created.
Support in all current engines.
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-downloads
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
allow-top-navigation-by-user-activation
allow-top-navigation-to-custom-protocols
When the attribute is set, the content is treated as being from a unique opaque origin, forms, scripts, and various potentially
annoying APIs are disabled, and links are prevented from targeting other navigables. The allow-same-origin
keyword causes the
content to be treated as being from its real origin instead of forcing it into an opaque origin; the allow-top-navigation
keyword allows the
content to navigate its traversable navigable;
the allow-top-navigation-by-user-activation
keyword behaves similarly but allows such navigation only when the
browsing context's active window has transient
activation; the allow-top-navigation-to-custom-protocols
reenables navigations toward non fetch scheme to be handed off to external software; 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. The allow-downloads
keyword allows content to
perform downloads. [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.
Similarly, the allow-top-navigation-to-custom-protocols
keyword must not be specified if either allow-top-navigation
or allow-popups
are specified, as doing so is
redundant.
To allow alert()
, confirm()
, and prompt()
inside
sandboxed content, both the allow-modals
and allow-same-origin
keywords need to
be specified, and the loaded URL needs to be same origin with the top-level
origin. Without the allow-same-origin
keyword, the content is
always treated as cross-origin, and cross-origin content cannot show simple
dialogs.
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 content navigable of the
iframe
element 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 content navigable 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 allow
attribute, when specified, determines the container
policy that will be used when the permissions policy for a
Document
in the iframe
's content navigable is initialized.
Its value must be a serialized permissions
policy. [PERMISSIONSPOLICY]
In this example, an iframe
is used to embed a map from an online navigation
service. The allow
attribute is used to enable the
Geolocation API within the nested context.
< iframe src = "https://maps.example.com/" allow = "geolocation" ></ iframe >
The allowfullscreen
attribute is a boolean
attribute. When specified, it indicates that Document
objects in the
iframe
element's content navigable will be initialized with a permissions policy which allows the "fullscreen
" feature to be used from any origin. This is enforced by
the process permissions policy
attributes algorithm. [PERMISSIONSPOLICY]
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 >
< p > Check out my new ride!</ p >
< iframe src = "https://video.example.com/embed?id=92469812" allowfullscreen ></ iframe >
</ article >
Neither allow
nor allowfullscreen
can grant access to a feature in an
iframe
element's content navigable if the element's node
document is not already allowed to use that feature.
Because they only influence the permissions policy of the content
navigable's active document, the allow
and allowfullscreen
attributes only take effect when the
content navigable of the iframe
is navigated. Adding or removing them has no effect on an already-loaded
document.
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 new child navigable, 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]
The loading
attribute is a lazy
loading attribute. Its purpose is to indicate the policy for loading iframe
elements that are outside the viewport.
When the loading
attribute's state is changed to the
Eager state, the user agent must run these
steps:
Let resumptionSteps be the iframe
element's lazy load
resumption steps.
If resumptionSteps is null, then return.
Set the iframe
's lazy load resumption steps to null.
Invoke resumptionSteps.
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&format=banner"
width = "468" height = "60" ></ iframe >
embed
elementSupport in all current engines.
src
— Address of the resource
type
— Type of embedded resource
width
— Horizontal dimension
height
— Vertical dimension
The embed
element provides an integration point for an external 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 string. 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.
The embed
element supports dimension attributes.
object
elementSupport in all current engines.
data
— Address of the resource
type
— Type of embedded resource
name
— Name of content navigable
form
— Associates the element with a form
element
width
— Horizontal dimension
height
— Vertical dimension
HTMLObjectElement
.The object
element can represent an external resource, which, depending on the
type of the resource, will either be treated as an image or as a child
navigable.
The data
attribute
specifies the URL of the resource. It must be present, and must contain a
valid non-empty URL potentially surrounded by spaces.
The type
attribute,
if present, specifies the type of the resource. If present, the attribute must be a valid
MIME type string.
The name
attribute, if present, must be a valid navigable target name. The given value is
used to name the element's content navigable, if applicable, and if present when the
element's content navigable is created.
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 >