Generador de códigos QR

Why the iframe tag is trickier than it looks

An <iframe> embeds one web page inside another — a YouTube video, a map, a CodePen demo. The tag itself is simple, but getting it right means juggling three separate security and performance systems that are easy to misconfigure: the sandbox attribute, the allow attribute, and the loading strategy. Misuse any of them and the embed either breaks (a video that will not play, a map that will not load) or quietly opens a security hole. This generator builds clean, copy-ready iframe code and lays those three systems out as explicit choices so you understand what each one does before you paste it into your page.

What the generated tag contains

For a typical embed the tool produces something like this, with each attribute on its own line for readability:

• src — the URL being embedded.
• width and height — accepting either a pixel number (600) or a percentage (100%) for the width.
• title — a human description of the frame.
• loading — lazy or eager, if you set one.
• allow — a semicolon-separated list of granted browser features.
• sandbox — a space-separated list of re-enabled capabilities, when sandboxing is turned on.
• style="border:0" — to remove the default inset border most browsers draw.

Sandbox: deny by default, then allow back

The sandbox attribute is a security wrapper. The crucial thing to understand is that adding an empty sandbox attribute applies the most restrictive setting possible — scripts cannot run, forms cannot submit, the frame cannot access cookies or navigate the top page. Each flag you then add re-enables one specific capability. So the model is "block everything, then grant back only what this embed genuinely needs." Common flags include allow-scripts (run JavaScript), allow-forms (submit forms), allow-same-origin (access its own cookies and storage), and allow-popups (open new windows).

One combination deserves a warning the tool's flag list makes possible: granting both allow-scripts and allow-same-origin to a frame from your own origin effectively lets the framed page remove its own sandbox, since it can reach back into the parent document. Only pair those two for content you fully trust.

The 'allow' attribute is a different thing entirely

It is easy to confuse allow with sandbox, but they govern different layers. sandbox controls broad capabilities like scripting and navigation; allow grants access to specific powerful browser features via Permissions Policy — camera, microphone, geolocation, fullscreen, payment, autoplay, and more. A video call embed needs allow="camera; microphone"; a fullscreen-capable player needs fullscreen; a video that should autoplay needs autoplay. Grant only the features the embedded page actually uses — every extra permission is unnecessary exposure.

A worked example with a preset

Click the YouTube preset. The tool fills in a YouTube embed URL, a 560×315 size, a descriptive title, and ticks the allow features YouTube needs — including autoplay, encrypted-media (for DRM-protected streams), picture-in-picture, and fullscreen. The output is a complete tag along the lines of:

• <iframe src="https://www.youtube.com/embed/…" width="560" height="315" title="YouTube video" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" style="border:0"></iframe>

Notice that this preset uses no sandbox — YouTube's player needs full scripting and same-origin access to function, so sandboxing it would break playback. By contrast the CodePen preset does enable a sandbox with allow-scripts allow-forms allow-same-origin, because untrusted user-submitted code is exactly the case sandboxing exists for. The presets demonstrate the judgment call: trusted first-party players run unsandboxed, arbitrary third-party code gets locked down.

The preview is intentionally locked down

The Load Preview button renders your iframe inside the page, but it always wraps the preview in a sandbox (even if you left sandboxing off in your output), and it only loads http or https URLs. That is a deliberate safety measure for testing untrusted URLs — the preview shows roughly how the frame will look without letting an unknown page run with full privileges in this tab. Your generated code still reflects exactly the attributes you chose; only the preview adds extra restriction.

Tips and common mistakes

• Always set a title. Screen readers announce the title to describe the frame, and an iframe without one is an accessibility failure under WCAG. The generator gives it a dedicated field for a reason.
• Use loading="lazy" for below-the-fold embeds. A heavy map or video iframe loaded eagerly delays your whole page. Lazy loading defers it until the user scrolls near it, improving initial load time. Keep eager only for embeds visible immediately on screen.
• Width can be a percentage, height usually cannot. Setting width to 100% makes the frame responsive to its container, but a percentage height collapses unless the parent has an explicit height. Give height a pixel value, or use an aspect-ratio wrapper around the frame.
• Many sites refuse to be framed at all. If your embed shows a blank box or a "refused to connect" message, the target site has set an X-Frame-Options or frame-ancestors header blocking embedding. No attribute on your side can override that — you must use the site's official embed URL.
• Don't over-grant. Copying a long allow list "just in case" is a habit worth breaking. Start from nothing and add only the features the embed visibly requires.

Privacy note

The code is assembled in your browser as you toggle options; nothing you configure is sent to a server. Note that when you actually use the iframe on your site, the embedded URL itself will load third-party content for your visitors — that is inherent to embedding, not to this generator.