Klaviyo Embedded Form: Why Sign-Ups Stop Converting

What Is a Klaviyo Embedded Form?

A Klaviyo embedded form is a sign-up block that lives inside a page’s own HTML, not layered on top of it. Unlike a pop-up or flyout, which Klaviyo injects as an overlay after a trigger fires, an embedded form sits wherever you place it in the template — a footer, a blog post’s sidebar, a landing page section — and renders the moment that part of the page loads. For a $3M–$30M Shopify Plus brand, this is usually the form doing the quiet, unglamorous work: the footer newsletter box, the post-purchase page opt-in, the blog-to-list capture that a pop-up would feel too aggressive for.

The mechanics are simple on paper. You build the form in Klaviyo’s form editor, choose “Embedded” as the form type instead of “Popup” or “Flyout”, and Klaviyo gives you a snippet of code with a unique form ID baked in. You paste that snippet into your theme, and Klaviyo’s script finds the container by that ID and renders the form fields, styling and submit logic inside it. The trouble starts because that dependency, a script matching a container by ID, is exactly the kind of thing that breaks without an error message. Nobody gets an alert. The box just sits there looking normal while it stops doing anything.

What You Need Before You Build One

Before you touch the form editor, four things should already be true. First, you need a Klaviyo account connected to your store with at least one active list or segment you’re building toward; building a form with nowhere for the data to land just produces profiles that never move into a flow. Second, someone on your team needs to have decided, in writing, whether new sign-ups go through single or double opt-in — that’s a list-level setting in Klaviyo, not a form-level one, and it changes what the form’s confirmation message should say. Third, you need template edit access, since an embedded form has to be pasted into Liquid, not dropped in through a drag-and-drop app block on every theme. Fourth, decide where the form is going before you build it, because targeting rules and layout both depend on the page it’s going into.

This guide is written for brands running Shopify Plus or an equivalent paid subscription platform, roughly $3M to $30M in revenue, with a Lifecycle or CRM function that already owns a flow strategy — see /for/scaling-brands for the fuller profile. If you’re pre-revenue or running a single monthly campaign with no flows behind it, the embedded form itself is the easy part; the harder problem is that you have nothing built to put the sign-up into once it arrives, and this guide won’t fix that.

How to Create a Klaviyo Embedded Form

Building an embedded form is a sequence of small decisions, most of which are easy to skip because Klaviyo’s defaults look finished. Here’s the order that avoids rework.

Step 1: Create a New Form and Choose Embedded as the Type

In Klaviyo, open Sign-up Forms, create a new form, and choose Embedded rather than Popup or Flyout at the type-selection step. This choice is effectively permanent for that form — Klaviyo doesn’t let you convert an embedded form into a pop-up later without rebuilding it, so decide the placement before you start on the layout.

Step 2: Set the List and Double Opt-In Behaviour

Every form submits to a specific list, chosen inside the form’s settings. Check that list’s own opt-in process (single or double) under its list settings, not the form’s — a form does not override what the list is already configured to do. If the list uses double opt-in, the confirmation message you write in the form has to say a confirmation email is coming, or the reader assumes they’re already subscribed when they’re not.

Step 3: Build the Content Block and Required Fields

Add the fields you actually plan to use downstream. Email is the only field most embedded forms need; anything beyond that — first name, birthday, SMS number — has to earn its place, because every extra required field measurably reduces submissions and gives you a field you now have to keep clean in every flow that reads it.

Step 4: Add the Consent Checkbox or Disclaimer Text

If you’re collecting a phone number for SMS, add an explicit consent checkbox or disclaimer text block near the submit button, not just in a footer link. Text consent generally needs to be opt-in and unambiguous — confirm the specific wording and requirements with counsel, because this varies by jurisdiction and channel, and Klaviyo’s default template text is a starting point, not a compliance guarantee.

Step 5: Set Targeting Rules for the Pages It Appears On

Even though an embedded form doesn’t pop up on a trigger, it still has targeting rules: which URLs it’s allowed to render on, and whether it should hide from profiles already on the list. Set the URL match explicitly rather than leaving it on a default that matches every page, or you’ll get the form rendering on order-confirmation and account pages where it makes no sense.

Step 6: Copy the Embed Code and Paste It Into the Theme

Klaviyo generates a short script and a container div with a unique ID for that form. Paste both into the theme section where the form belongs — a Liquid file if you’re not using a page builder, or the raw HTML block if your theme has one. This is the step that most often gets handed to whoever touched the theme last, and it’s worth being the one who checks it went into the right file.

Step 7: Publish the Form and Confirm It Renders

Publish the form inside Klaviyo — a saved draft doesn’t render on the live page, even with the embed code already pasted in. Then load the actual page in an incognito window, not the theme editor’s preview, because theme previews sometimes render cached sections that hide a broken embed.

Where to Find the Klaviyo Embedded Form ID

Every Klaviyo form has a form ID, a short alphanumeric string that ties the container on your page to the specific form record in Klaviyo. Support threads and community posts often call this the embedded form ID in Klaviyo, and it’s the identifier every debugging step in this article depends on. You’ll need it any time you’re checking why a form isn’t showing, or when you want to confirm two pages are actually pointing at the same form rather than two different ones that happen to look identical.

The fastest way to find it is inside the form editor itself: open the form in Klaviyo, and the ID appears in the URL of the editing page. It’s also embedded directly in the snippet you copied in Step 6 — look for the identifier inside the container div or the script call, and match it against what’s actually live on the page using your browser’s “view page source” rather than the rendered DOM, since some page builders inject content after load. If you manage forms through the API, the Forms endpoint lists every form on the account along with its ID and status, which is the more reliable way to audit a page with more than a handful of forms scattered across it.

How to Capture Consent Correctly in an Embedded Form

Consent on a sign-up form has one job: recording, at the moment of submission, what the person actually agreed to and for which channel. An email address does not imply consent for SMS, and a completed purchase does not imply marketing consent for either channel. A checkout is a transaction, not an opt-in, and treating it as one is a common and avoidable way brands end up messaging people who never agreed to hear from them.

For email, Klaviyo’s list-level opt-in setting does most of the enforcement: single opt-in adds the profile as subscribed immediately, double opt-in sends a confirmation email and only marks the profile subscribed once that’s clicked. An embedded form doesn’t need its own separate email consent checkbox if the list is already handling this — layering an extra unchecked-by-default box on top just adds friction without adding a compliance benefit, and the confusion this causes is exactly what a compliance review tends to flag.

For SMS, the requirements are stricter and more jurisdiction-specific. Consent for text messages typically needs to be explicit, separate from email consent, and clearly worded at the point of collection, but the specifics — required language, what counts as sufficient, record-keeping obligations — vary and change, so this is an area to confirm directly with counsel rather than copy from a template you found elsewhere.

Two implementation details cause most of the real-world consent problems on embedded forms: a pre-checked consent box, and a lost consent record. Defaulting a checkbox to checked and asking the visitor to opt out rather than in is a pattern regulators and platforms increasingly treat as invalid consent, and it also inflates your subscriber count with people who never meant to join. Losing the consent record itself is the other failure — if the checkbox state isn’t captured as a profile property or event at submission, you end up with a subscribed profile and no record of what they agreed to, which is a real problem if anyone ever asks why they’re receiving texts.

Where to Place an Embedded Form So People Actually See It

Placement decides more of an embedded form’s performance than its design does, because unlike a pop-up, it never interrupts anyone. It only works if it happens to be somewhere a reader’s eye naturally lands.

The footer is the placement most stores default to, and it’s also the weakest one: footer scroll depth on a typical product or blog page is low, and the people who do scroll that far are often looking for a returns policy or size guide, not a reason to hand over their email. A footer form still belongs on the page, but treating it as your primary capture point sets an unrealistically low expectation of what the form format can do.

Stronger positions share one trait: they sit at a point where the reader has already decided to stay. Inline in the body of a blog post, after the point where someone would have bounced if they weren’t interested, converts better than a form bolted above the title. On a landing page, a form placed directly under the section that made the argument — after the proof, not before it — captures people at the moment they’re convinced rather than asking them to commit blind. A post-purchase or order-confirmation page can hold an embedded form for a second list, such as a loyalty programme or a VIP tier, without competing with the transactional messaging, provided it’s visually separated from anything that looks like part of the checkout itself.

Avoid placing an embedded form inside content that loads conditionally — a tab that isn’t the default, an accordion that starts collapsed, a carousel slide beyond the first. Klaviyo’s script looks for the container div when the page loads; if that container is present in the DOM but hidden, the form usually renders correctly once revealed, but some themes strip hidden sections out of the initial DOM entirely and inject them only on interaction. In that case the script runs before the container exists at all, and the form never appears.

How to Target an Embedded Form to the Right Visitors

Targeting on an embedded form controls where it’s allowed to appear, not whether it pops up, and that distinction trips people up because the settings panel looks identical to the one on a pop-up form. Set the URL match to the specific page or path pattern you actually want, rather than accepting a default that matches the whole site; a “contains” match on a short string can accidentally catch pages you never intended, particularly on a Shopify store where collection and product URLs often share a common prefix.

Suppress the form from anyone already on the target list. Without this rule, a subscribed customer keeps seeing the same footer form on every visit, which does nothing but make the page feel unfinished. Klaviyo can check list or segment membership as part of a form’s targeting, and it’s worth setting this even on embedded forms, since suppressing on segment membership is the only thing that stops an already-converted visitor being asked again.

Device-based targeting matters more for embedded forms than it looks like it should. A form built and reviewed on a desktop monitor can render fine there and break on mobile — a two-column layout collapsing into a field that’s cut off by the viewport edge, or a submit button pushed below the visible fold on a smaller screen. Given that most Shopify traffic for a scaling brand arrives on mobile, checking the mobile rendering isn’t optional polish; it’s most of your actual audience.

Why Klaviyo Embedded Forms Silently Stop Converting

An embedded form that stops working rarely throws an error. It just keeps rendering while the submissions that should be flowing into a list quietly stop, and because nobody’s watching a chart of form-specific sign-ups day to day, this can run for weeks before anyone notices flow volume looks thin. A few mechanisms account for most of it.

A theme update is the most common cause. Shopify Plus stores that pull updates from a theme’s source repository, or accept a vendor’s scheduled push, can have the section containing the embed code overwritten wholesale. The visual footer looks the same because the theme’s own native newsletter box fills the same space, but Klaviyo’s script and container are simply gone. Nothing about this throws a build error, because from the theme’s point of view nothing is broken; a form is still there, just not Klaviyo’s.

A cookie consent banner can also block the script itself. If your consent management setup only allows marketing or “non-essential” scripts to load after the visitor accepts cookies, and Klaviyo’s embed script is classified under that category, the form’s container renders empty until consent is given. That’s defensible from a compliance standpoint, but worth knowing about explicitly rather than discovering when sign-up numbers from a particular region look wrong and nobody can explain why.

A duplicated form ID from a copied section is the third cause, and it’s the one worth reading twice, because it doesn’t look like a failure at all: the form still renders, still accepts a submit click, and still looks finished.

The Step Most Teams Get Wrong When They Duplicate a Form Section

The failure that’s hardest to catch is the one that looks identical to success. When a developer duplicates a page section in the theme editor — copying a “Newsletter” block to build a second one for a new landing page, or cloning a footer for a regional storefront — the embed’s container div and script call come along in the copy unchanged. Klaviyo’s script matches the container by its class, and that class is unique to the original form, not regenerated per copy. The result is two visible forms on two different pages, both correctly styled and both accepting input, but only one of them is actually wired to a live form ID; the other is either inert or, worse, still pointed at the original form’s list, quietly adding every submission from the new page to a list that has nothing to do with it.

The form ID itself is the detail worth checking directly rather than assuming your theme is fine: open every page that’s supposed to have its own embedded form, view source, and confirm the form ID in each container is actually different where the forms are meant to be different. If two pages share an ID they shouldn’t, one of them is a duplicate that never got repointed, and because both render and both accept a submit click, nothing about looking at the page will tell you this happened. It only surfaces when someone checks submission counts against the specific form ID inside Klaviyo, not against the page.

How to Verify an Embedded Form Is Actually Capturing Sign-Ups

A form that looks right on the page is not the same as a form that works. Verification means submitting a real test entry and following it all the way to a list.

Submit the form yourself with an email address you control, using an incognito window on the live URL rather than a theme preview. Then check three things in order: that a new profile appears in Klaviyo with that email, that the profile shows the correct list membership (not just that it exists, but subscribed to the list the form is supposed to feed), and that the consent or opt-in status recorded on the profile matches what you’d expect from the list’s opt-in setting.

After that, check the form’s own reporting inside Klaviyo. Views and submissions are tracked per form ID, and a form with steady views but a submission count near zero is the clearest sign something downstream of the click is broken, whether that’s a validation error, a duplicated container, or a list that no longer exists. Compare this against the flow it’s meant to feed: if a welcome flow depends on this form and its entry count has gone flat while the form’s own view count hasn’t, that’s the gap worth chasing before anything else. Across Klaviyo’s own merchant base, automated flows account for 41% of email revenue (Klaviyo, 183,000+ brands, vendor-reported), which is roughly the scale of what’s at stake when an entry point into one goes quiet. The flow revenue calculator is a reasonable way to put a rough number on what a stalled entry point into a welcome flow is actually costing before you prioritise fixing it.

Set a recurring calendar reminder, not a one-time check, especially around theme updates or a site redesign — verification at launch tells you the form worked on day one, not that it still works after the next push.

Klaviyo Embedded Form vs Popup Form: Which Should You Use?

The row worth acting on is the failure mode one: a popup form failing is usually obvious because a human notices it stopped interrupting them, while an embedded form can fail invisibly for exactly the reason it’s a better on-page citizen in the first place. Most $3M–$30M stores end up running both — an embedded form for the pages where a popup would feel wrong, and a popup for the traffic that’s about to leave without ever scrolling far enough to see the embed at all.

An embedded form that silently stops working isn’t a form problem in isolation — it’s a gap in whatever list-growth and flow-entry engineering is supposed to be watching for it, which is exactly the kind of thing a Lifecycle flows programme should be catching before a quarter goes by on a stalled welcome series.