iFrame Studio

Test URL embedding, sandbox flags, Permissions Policy allow for WebAuthn in iframes, and cross-origin postMessage traffic.

Privacy: Client-Direct + Server-Proxy. Prefer browser fetch() to the IdP. On CORS failure or confidential clients, fall back to /api/v1/proxy/token. Credentials and assertions are not retained.

Debug SSO embeds, payment widgets, passkey-in-iframe Permissions Policy, and postMessage bridges. Preview runs in your browser; framing header audits use a short-lived server probe for public URLs (localhost skipped).

Enter a URL and click Load

1280×720 · no sandbox

Permissions / allow

Controls the iframe allow attribute (Permissions Policy). Required for WebAuthn inside a cross-origin frame.

WebAuthn

Other delegated features

(omitted — toggle Apply allow)
(none — enable features above)

Only needed if the top-level page already restricts these features via HTTP headers. utilxo.com itself does not set a blocking policy for this tool.

  • WebAuthn uses the iframe document origin (not the parent). rp.id must match that origin (or a valid registrable domain suffix).
  • Secure context required: https: (or http://localhost).
  • Call credentials.create/get from a user gesture inside the iframe (button click).

Sandbox policy

Without sandbox, the frame runs with the browser's default iframe privileges (still subject to the target's framing headers).

postMessage terminal

Incoming and outgoing messages appear here.

Why do iframes fail to embed?

Browsers refuse to frame pages that send X-Frame-Options: DENY/SAMEORIGIN or a restrictive Content-Security-Policy frame-ancestors directive. Mixed content (HTTPS parent embedding HTTP) also blanks the frame. SSO, OAuth widgets, payment embeds, and passkey flows hit these rules constantly.

iFrame Studio loads a candidate URL in a controllable iframe, probes public framing headers via a short-lived proxy, simulates HTML sandbox and allow (Permissions Policy) attributes, and logs window.postMessage traffic so you can validate cross-origin contracts safely.

How to use this tool

  1. Paste a URL (or pick a preset), click Load / Audit headers, and read the embed verdict.
  2. For passkeys in an iframe: open Permissions / allow, pick a WebAuthn preset (get, create, or both), set allowlist origins (or *, self, src), then reload the frame.
  3. Toggle sandbox flags and viewport size to mimic production embed constraints. Use the postMessage terminal to send JSON/string payloads and inspect inbound events.

Frequently asked questions

Can you probe localhost headers?

No — the server header probe blocks private hosts. You can still load http://localhost in the iframe from your browser for local widget testing.

Is framed content uploaded to Utilxo?

The live preview runs in your browser. Header audits fetch only framing-related response headers for public URLs and do not store bodies.

Why warn about allow-scripts + allow-same-origin?

Together they can let same-origin framed content remove the sandbox attribute, defeating the isolation model for untrusted embeds.

Why does WebAuthn fail inside my iframe?

Cross-origin iframes need an allow attribute with publickey-credentials-get and/or publickey-credentials-create (and a matching Permissions-Policy on the parent if the parent restricts features). The ceremony uses the iframe document origin for rp.id, requires a secure context, and must run from a user gesture inside the frame.

Can I change allow combinations without editing code?

Yes. Use Permissions / allow presets and per-feature toggles (mode: *, self, src, or custom origins). Settings persist in localStorage; the live iframe remounts when allow or sandbox changes.