HTML Iframes: Embedding One Page Inside Another

An iframe lets you drop another web page right inside your own — a map, a video, a payment form. Learn how the iframe element works, its key attributes, the security settings that matter, and when to use one (and when not to).

Published August 5, 202610 min readBy ACY Partner Indonesia
HTML iframes — embedding an external page inside your own
300 × 250Ad Space AvailablePlace your ad here

You’ve probably seen a Google Map sitting inside an article, a YouTube video playing on a blog that isn’t YouTube, or a “pay here” box on a checkout page that clearly came from a payment provider. All of those are usually the same trick: an iframe. It’s a single HTML element that lets you embed an entire other web page inside your own, like a window cut into your document that shows somebody else’s page through it.

In this article you’ll learn what an iframe actually is, how to write one, the attributes that matter (including the security ones you should never skip), and — just as important — when an iframe is the right tool and when it quietly causes problems.

What an iframe is

The word iframe stands for inline frame. It’s an HTML element, <iframe>, that loads a separate web page and displays it as a rectangular region inside your current page. That embedded page is a fully independent document: it has its own HTML, its own CSS, its own JavaScript, and it loads from its own URL.

Here’s the smallest possible example:

<iframe src="https://example.com"></iframe>

The src attribute is the address of the page you want to embed — exactly like src on an image or a script. The browser fetches that URL and paints the result inside the frame. Everything inside that rectangle belongs to the other page; everything outside it is still yours.

A useful mental model: your page is a wall, and an iframe is a window in that wall. Through the window you can see another room (another page), but you’re not standing in that room. The two stay separate — and as you’ll see, that separation is both the iframe’s biggest strength and its biggest limitation.

Writing your first iframe

<iframe> is a normal element with an opening and closing tag, though it’s almost always written self-contained because you don’t put your own content between the tags. A few attributes do the heavy lifting:

<iframe
  src="https://www.openstreetmap.org/export/embed.html"
  width="600"
  height="400"
  title="Map of the city center"></iframe>
  • src — the URL of the page to embed. This is the one attribute you can’t do without.
  • width and height — the size of the frame in pixels. Without them, the browser uses a default size (often 300×150) that’s rarely what you want.
  • title — a short, human-readable description of what the frame contains. This isn’t decoration: screen readers announce it, so leaving it out makes your page harder to use for people who rely on assistive technology.

Anything you write between the opening and closing tags is fallback content for very old browsers that can’t render iframes — which is essentially none today, so you’ll usually just leave it empty.

Always give an iframe a title

The title attribute is the single easiest accessibility win with iframes. A screen-reader user moving through your page will hear “Map of the city center, frame” instead of an anonymous, unlabeled box they have to guess about. It costs you one short sentence — write it every time. If you’ve read the article on HTML attributes, you’ll recognize title as one of the global attributes — on an iframe it does real accessibility work, not just a tooltip.

Sizing an iframe properly

By default an iframe has a fixed pixel size and a border around it. Two things trip people up here, so let’s deal with both.

First, the border. Browsers used to draw a chunky frame around iframes. You can switch it off with CSS, which is the modern way:

<iframe
  src="https://example.com"
  width="600"
  height="400"
  title="Example page"
  style="border: none;"></iframe>

Second, responsiveness. A hard-coded width="600" looks fine on a laptop but overflows a phone screen. The common fix is to make the iframe fill its container’s width and use CSS to lock the aspect ratio so it doesn’t get squashed:

<div style="max-width: 600px;">
  <iframe
    src="https://www.youtube.com/embed/dQw4w9WgXcQ"
    title="Demo video"
    style="border: none; width: 100%; aspect-ratio: 16 / 9;"></iframe>
</div>

Here the iframe stretches to 100% of the wrapping <div>, and aspect-ratio: 16 / 9 keeps it the right shape for a widescreen video on any screen size. This little pattern is how almost every modern “embed this video” snippet works under the hood.

The width/height attributes vs CSS

You can set size with the width/height attributes or with CSS. When both exist, CSS wins. For responsive layouts, prefer CSS — but it’s still good practice to keep the width and height attributes too, because they tell the browser the frame’s shape before the CSS loads, which prevents the page from jumping around as it renders.

Common real-world uses

Iframes show up in a handful of very specific situations. Knowing them helps you recognize when an iframe is the natural answer.

  • Maps. Google Maps and OpenStreetMap both give you a ready-made iframe snippet so a live, pannable map appears on your page without you writing any map code.
  • Videos. YouTube, Vimeo, and similar services hand you an iframe that embeds their player. The video, its controls, and its tracking all stay on their side.
  • Third-party widgets. Payment forms, chat widgets, comment systems, and “calendar booking” tools are often delivered as iframes, so the provider controls the sensitive parts.
  • Sandboxed previews. Tools that let you write code and see the result (code playgrounds) frequently render the live preview in an iframe, keeping the user’s code isolated from the surrounding app.

Notice the pattern: an iframe shines when the embedded thing is a self-contained mini-application owned by someone else that you want to drop in without rebuilding it yourself.

Security attributes you should actually use

Because an iframe loads someone else’s page into yours, it comes with real security considerations. Two attributes are your main controls, and you should treat them as part of writing an iframe, not an afterthought.

The sandbox attribute

sandbox locks the embedded page down. With it present, the framed page is stripped of dangerous capabilities by default — it can’t run scripts, submit forms, trigger downloads, or break out into your page. You then add back only the permissions you actually need, one keyword at a time:

<iframe
  src="untrusted-widget.html"
  sandbox="allow-scripts allow-same-origin"
  title="Untrusted widget"></iframe>
  • sandbox with no value = maximum lockdown (no scripts, no forms, nothing).
  • sandbox="allow-scripts" = scripts allowed, everything else still blocked.
  • You combine keywords with spaces to grant exactly the permissions required, and nothing more.

The mindset is “deny everything, then allow the minimum” — the safest default when you’re embedding content you don’t fully trust.

The allow attribute

Where sandbox is about restriction, allow controls access to powerful browser features like the camera, microphone, geolocation, or fullscreen. A video embed, for instance, commonly needs fullscreen permission:

<iframe
  src="https://www.youtube.com/embed/dQw4w9WgXcQ"
  title="Demo video"
  allow="fullscreen; picture-in-picture"></iframe>

If you don’t list a feature in allow, the embedded page can’t use it — so a random embedded page can’t silently ask for the visitor’s camera. That’s the protection working as intended.

Only embed sources you trust

An iframe runs another site’s code in your visitor’s browser. If that site is malicious or gets compromised, your users are exposed through your page. Two rules keep you safe: only embed URLs from sources you genuinely trust, and use sandbox (granting the bare minimum) whenever you embed anything you don’t control. Never paste an iframe snippet from a random site just because it looks convenient.

Why pages can’t be put in your iframe

Try to embed a site like Google or a bank into your own page and you’ll often get a blank box or an error instead. That’s deliberate. Sites can tell the browser “don’t let anyone load me inside an iframe” using a response header (such as X-Frame-Options or a frame-ancestors rule in their Content Security Policy).

Why would they block it? Mainly to prevent clickjacking — an attack where a malicious page invisibly frames a real site (like your bank’s login) and tricks you into clicking things you didn’t mean to. By refusing to be framed, sensitive sites shut that attack down. So if an embed mysteriously refuses to load, this is usually the reason: the other site has chosen not to be embeddable, and there’s nothing wrong on your end.

The separation between an iframe and its host page

Remember the “window in a wall” image. Because the embedded page is a separate document, your page and the iframe normally can’t reach into each other. Your page’s CSS doesn’t style the iframe’s contents, and your JavaScript can’t read or change what’s inside it — and vice versa.

This is a feature, not a bug. It’s what makes iframes safe enough to embed strangers’ content at all: the embedded payment form can’t snoop on your page, and your page can’t tamper with the payment form. The one exception is when both pages come from the same origin (same protocol, domain, and port), in which case they’re allowed to talk to each other via JavaScript. For embeds from other sites, the wall stays up, by design.

When an iframe is the wrong choice

Iframes are powerful, but reaching for one out of habit causes trouble. Skip the iframe when:

  • You just want to show your own content. If the embedded page is yours, you’re usually better off building that content directly into the page. A separate document means a second full page load, its own styles, and a harder time making everything responsive together.
  • You need the contents to interact with your page. Because of the separation above, an iframe is a poor fit when the embedded thing must read your page’s data or react to it.
  • SEO matters for that content. Search engines treat the framed page as a separate document; text inside an iframe generally doesn’t count as content on your page. Don’t put important, indexable copy in an iframe.
  • Performance is tight. Every iframe is effectively a whole extra page being loaded — more requests, more memory. A page stuffed with iframes feels heavy and slow.

A good rule of thumb: use an iframe to embed a self-contained tool or media owned by someone else, and avoid it for your own content or anything that needs to be woven into your page.

Wrapping up

The iframe is a small element with an outsized job: it lets one page host another, fully independent page inside it. The essentials:

  • An <iframe> embeds a separate web page via its src, displayed as a region inside yours.
  • Always set width, height, and a title — and use CSS (border: none, width: 100%, aspect-ratio) to make it tidy and responsive.
  • The embedded page is fully isolated from yours unless they share the same origin — your CSS and JS can’t reach in, which is exactly what keeps the arrangement safe.
  • Use sandbox to lock down untrusted content (deny everything, then allow the minimum) and allow to grant access to features like fullscreen or the camera.
  • Sites can refuse to be framed to prevent clickjacking, so some embeds simply won’t load — and that’s their decision, not your mistake.
  • Reach for an iframe to embed someone else’s self-contained tool or media, and avoid it for your own content, for things that need to interact with your page, or where SEO and performance are critical.

Used in the right spot — a map, a video, a trusted third-party widget — an iframe saves you an enormous amount of work. Used in the wrong spot, it adds weight and walls off content that should have been part of your page. Now you can tell the two apart.

Tags:htmlfrontendiframeembeddingintermediate
728 × 90Ad Space AvailablePlace your ad here

Related Articles

See All Articles

You Might Also Like

Frontend best practices overview cover
Frontend / Fundamentals

Frontend Best Practices: An Overview

A friendly map of what good frontend really means — semantic HTML, clean CSS, unobtrusive JavaScript, responsive layouts, performance, and progressive enhancement, with pointers to go deeper.

Sep 20, 20268 min read
A Frontend Developer Roadmap cover with the path HTML to CSS to JavaScript
Frontend / Fundamentals

A Frontend Developer Roadmap: What to Learn, and in What Order

A calm, step-by-step learning path for beginners: HTML, CSS, JavaScript, developer tools, responsive and accessible design, a framework, TypeScript, and deployment, with the reasoning behind each step.

Sep 20, 202611 min read
Title card reading Styling and Interactivity over a dark blue ACY Partner background
Frontend / Fundamentals

How Styling and Interactivity Work

A beginner-friendly look at how CSS turns plain HTML into a designed layout, and how JavaScript adds behavior — the structure, style, behavior mental model for building web pages.

Sep 20, 20269 min read
Three front-end layers combining on one web page
Frontend / Fundamentals

How HTML, CSS, and JavaScript Work Together

A hands-on walkthrough for beginners: build one small button, give it structure with HTML, looks with CSS, and behavior with JavaScript, and watch the three layers cooperate on a real page.

Sep 20, 20268 min read
The Frontend Developer Toolkit cover with editor, browser, and CLI motifs
Frontend / Fundamentals

The Frontend Developer Toolkit

A friendly tour of the everyday tools a frontend developer relies on — code editor, browser and DevTools, terminal, version control, package managers, and a dev server — and what each one is actually for.

Sep 20, 202610 min read
Cover illustration for What Frontend Developers Do
Frontend / Fundamentals

What Frontend Developers Do: A Beginner's Guide to the Role

A clear, beginner-friendly look at what frontend developers actually do every day: turning designs into working interfaces, building reusable UI, and caring about responsiveness, accessibility, and speed.

Sep 20, 202610 min read