Show Known Visitor HTML on other open tabs after a form submit

Known Visitor HTML lets you un-gate assets if the viewing lead is already known, so they just see a direct download button. But as a completist, I’ve always been irked by the fact that forms on other open tabs still show unless the lead manually refreshes. Those forms feel like sitting ducks for conflicting form data and unnecessary friction.

If I’ve piqued your irk-terest, it remarkably easy to solve this using the BroadcastChannel API in all modern browsers.

What’s a BroadcastChannel?

BroadcastChannel offers guaranteed-secure, cross-window, same-origin messaging. You don’t need to worry about cross-origin security because the browser simply won’t allow cross-origin anything over a BroadcastChannel.

(In contrast, the more familiar postMessage API can be secure if both sides enforce origin verification, but an inattentive dev can introduce leaks. postMessage lets you communicate cross-origin, so it’s more powerful overall, but we don’t need it today.)

Check the recording below to see the effect we’re going for. On the left is Page L with Form 123; on the right is Page R also with Form 123. When you submit the form on Page L:

(1) the PDF set as the Thank You URL opens

— and simultaneously, in the background —

(2) the form on Page R is replaced by KV HTML with just a button; should the person switch to Page R later, they can jump right to the PDF

Get the code

Thanks to BroadcastChannel’s guaranteed security, the code is remarkably short:

/**
 * BroadcastChannel to send success data to other tabs and switch to KV HTML
 * @author Sanford Whiteman
 * @version v1.0.0 2026-07-08
 * @license Hippocratic 3.0: This license must appear with all reproductions of this software.
 *
 */
const successChannel = new BroadcastChannel("form.success");

MktoForms2.whenReady(function(readyForm){
   readyForm.onSuccess(function(submittedValues,thankYouHref){
      successChannel.postMessage(submittedValues);
   });
});

successChannel.addEventListener("message",function(e){
   const thisForm = MktoForms2.getForm(e.data.formid);

   if( thisForm ) {
      const formEl = thisForm.getFormElem()[0];

      // already showing KV HTML?
      if( formEl.querySelector(".mktoTemplateBox") ) return;

      // first non-null field from broadcast, current, random
      window.mktoPreFillFields = window.mktoPreFillFields ?? {};
      const requiredKVFields = ["FirstName", "LastName"];
      requiredKVFields.forEach( (field) => window.mktoPreFillFields[field] = e.data[field] ?? window.mktoPreFillFields[field] ?? crypto.randomUUID() );

      MktoForms2.allForms().splice(MktoForms2.allForms().indexOf(thisForm), 1);      
      formEl.innerHTML = "";      
      MktoForms2.loadForm(`//${e.data.munchkinId}.mktoweb.com`, e.data.munchkinId, e.data.formid);
   }
});

Code Anatomy: KV HTML’s quirked-up rules

As I’ve noted before, Known Visitor HTML has an undocumented prerequisite: it only works if the visitor has a non-empty First Name and Last Name.

This is fairly logical given that you can include tokens for those fields — but only those fields — in the KV HTML.[1] (And yes, the tokens work even when the form embed is used on non-Marketo pages.)

You don’t have to include those fields in KV HTML, though: you can just show a button or link. Yet even if you don’t output First or Last on the minimal KV HTML form, the prereq still applies! Marketo checks for known visitor data in two places, in this order:

(1) the global mktoPreFillFields object, present on Marketo LPs with native Pre-Fill enabled

(2) the getKnownLead JSONP endpoint, used by the form embed on non-Marketo LPs and by Progressive Profiling (on any LP)

Since mktoPreFillFields is checked first, the code ensures a usable mktoPreFillFields is always present. It prefers the FirstName and LastName from the form that triggered the BroadcastChannel message; if those weren’t posted, it’ll fall back to an existing mktoPreFillFields; and finally, it’ll generate random values so KV HTML kicks in.

Therefore, if your triggering form doesn’t have First Name and Last Name on it and you’re using a non-Marketo LP, you shouldn’t use the corresponding tokens in the KV HTML because you don’t want random values shown. Just have a link or button, like I did in the recorded demo.

It doesn’t even require cookies

An incidental frill here is the code works even if cookies are disabled. KV HTML usually requires either an associated mkto_trk cookie or a fresh mkt_tok param. Since the BroadcastChannel is sending data between currently open windows, there’s no need for persistence (message events are ephemeral, never cached/retried.)

Notes

[1] First Name and Last Name are also, to put it mildly, good to know. Given the chance to have a lead provide those values, you usually want to take it — but not always! Email-only records can be fine until they reach a high-value form that requires more fields. If your KV HTML-enabled form had only Email Address (plus some hidden attribution fields) on it, why show that “full” form again, right?