Modern lead collection doesn’t always happen on the page you’re looking at.
Many websites today load their forms dynamically, often inside iframes. This is especially common with third-party form providers, embedded CRMs, scheduling tools, and fraud or compliance widgets. From a user’s perspective, it all feels like one seamless page. From a browser’s perspective, it absolutely is not.
That distinction matters when it comes to recording user activity.
Why iframed forms are different
An iframe is essentially a webpage running inside another webpage. Even though it’s visually embedded, the iframe has its own document, its own DOM, and its own execution context. Browsers enforce very strict isolation between the parent page and the iframe for security reasons.
Because of that isolation, scripts running on the main page cannot see what happens inside the iframe. They can’t listen for keystrokes, clicks, input changes, or even reliably inspect the iframe’s DOM. This isn’t a FormClue limitation, but rather how the web platform itself is designed.
If a lead enters their name, email, or phone number into a form that lives inside an iframe, that interaction is invisible to any recording tool that isn’t running inside that iframe.
Why “just capturing the iframe” isn’t realistic
You might reasonably wonder why FormClue doesn’t simply “pull in” iframe content during session recording.
To do that properly, a recorder would need to recursively crawl every iframe, treat each one as a separate page, record it independently, and keep those recordings in sync over time. On top of that, it would need to handle cross-origin restrictions, dynamically injected iframes, and iframe content that changes after load.
At that point, you’re no longer recording a single page – you’re orchestrating multiple isolated documents that were never designed to be stitched together. The complexity, performance cost, and failure modes increase dramatically, with very little upside.
This is why FormClue does not attempt to auto-capture iframe internals by default. It’s also why our main competitor, TrustedForm, behaves the same way.
How to capture iframe-based forms with FormClue
The solution is straightforward once you understand the boundary.
If you want FormClue to record activity inside an iframe, the FormClue script must be installed on the page that is being iframed.
In practical terms:
- The parent page records everything that happens on the parent page.
- The iframe records everything that happens inside the iframe, but only if FormClue is running there.
When FormClue is installed inside the iframe, it treats that iframe like any other page. Inputs, clicks, DOM changes, and timing are captured normally and can be replayed and audited just like a non-iframed form.
If you control the iframe source (for example, it’s your own hosted form or application), adding FormClue there is all that’s required. If the iframe is owned by a third party and you cannot add scripts to it, then recording activity inside that iframe is simply not possible with any client-side tool.