Best Website Widgets for Webflow

The plan gate comes first

Webflow prints the same requirement atop two help articles, one for site and page custom code and one for the Code Embed element: you need a Core, Growth, Agency or Freelancer Workspace, or a site with an active Site plan. Its pricing table says it from the other direction: the custom code row is a dash in both the free Starter site plan column and the free Starter Workspace column.

So the cheapest way in is a paid Site plan on the one site, or a paid Workspace. On webflow.com/pricing as of August 25, 2026, in the yearly billing view, the Basic site plan is listed at $15 per month and the Core Workspace at $19 per month, with custom code named in the Core feature list. On a free account there is no partial version to try: the fields are not in the interface.

One loader, then the second widget costs a div

The loader goes in Site settings, Custom code tab, Footer code section. Webflow emits that section before the closing </body> tag on every page, and recommends the footer for script tags specifically. Save changes, and it ships with everything you publish after that.

<script src="https://bootsignal.com/bootsignal.js"
        data-site-id="YOUR_SITE_ID" data-lang="en" defer></script>

That is the only script tag involved. Everything after it is markup: open the Add panel, drop a Code Embed where the widget belongs, paste a div with a data-bootsignal attribute, save and close the modal. A countdown on a landing page is this much, and the tenth widget looks the same.

<div data-bootsignal="countdown"
     data-target="2026-12-31T23:59:59"
     data-expired="The sale has ended!"></div>

The billing has the same shape, which is worth knowing before you plan a layout. One registered domain runs $20 a month, or $200 for a year, and that single line covers the whole catalog, the widgets added after you subscribe included. Nothing in it counts pageviews or visitors, so planning three widgets instead of one does not move the number. A second domain is its own line item, added from the dashboard, and the pricing page has the rest.

One structural detail runs in Webflow's favor: a Code Embed puts your markup in the page itself, not inside a sandboxed iframe. The widget checks location.hostname against the domains registered for your site id, and Google sign-in checks the page origin. On builders that only offer a sandboxed HTML embed, the widget sees the builder's sandbox domain instead of yours and refuses to run. Webflow is not one of those. Register your live domain, plus the .webflow.io staging domain if you test first, and the check passes.

When you want readers to say something back

Comments earn their place on pages that take a position or explain a procedure, because that is where readers have a correction or a question to add. Visitors sign in with Google, and that sign-in is shared across every BootSignal widget. On a collection page the whole install is one template edit: steps are in the Webflow comment widget guide, and the widget is Comments.

Ratings fit a different kind of page: one where the visitor is judging a thing rather than discussing it. A template, a recipe, a course module. What it collects also feeds the Testimonial Wall, which builds its cards from reviews the widget actually stored, so it cannot show a quote nobody wrote. Ratings takes a thread id, because the score belongs to the item, not the site.

When a date is doing the selling

A countdown is either honest or it is decoration. If enrollment really closes Friday, or the price really changes at midnight, the timer states something true and the page reads more urgently for it. Set data-target to an ISO timestamp and data-expired to whatever the page should say afterward, the part people skip until the clock hits zero. Install steps are in the Webflow countdown widget guide.

The Social Proof Toast is the other half of urgency, and it is deliberately weaker than the faked version other tools sell. It replays your site's real recent activity, the comments, reactions, ratings and votes BootSignal already stores, and it cannot invent a purchase in Ohio because there is no field to type one into. So on a site nobody has used yet, the toast has nothing to show. It belongs on pages with some activity behind them.

When the page is long and people leave halfway

Two widgets answer the same complaint from opposite ends. Reading progress is a slim bar at the top that fills as the visitor moves down, so they know how much is left without dragging the scrollbar. The table of contents builds itself from the headings already on the page and highlights the section being read, which is what a long guide or a docs page wants. Neither takes a thread id, because neither stores anything.

Share belongs in this group for a plainer reason: hand-built share links rot, and nobody notices until a button posts a blank page. The share widget is one element that hands off to the device's native share sheet where the browser has one, and copies the link where it does not.

When you are collecting email addresses

Newsletter is the one widget here a Webflow user may already have a native answer for, since a Webflow form can collect an address and store the submission. The difference is where the address lands. The newsletter widget keeps signups with the rest of your BootSignal data, asks the visitor for no sign-in, and takes a data-thread-id, so a blog list and a waitlist can run from one site without two forms.

Thread id or no thread id

This is the thing Webflow users get wrong, because Webflow makes the wrong version easy. Inside a Code Embed on a collection page template you can drop a CMS field straight into an attribute value, which is the right instinct about half the time. Widgets that store something about a specific page take data-thread-id and want that binding; widgets that only read the page they sit on ignore it. Hard-code one value across every post and all your posts share a single conversation.

The rule covers the widgets not on this page too. Polls, guestbook, upvote, reactions, view count and feedback keep per-page data, so they take a thread id. Announcement bars, cookie consent, lightbox, gallery, image compare, magnify, split flap, mind maps, the testimonial wall and effects do not.

What the Designer shows you and what it hides

• A Code Embed containing a <script> tag shows only a placeholder on the Designer canvas. Webflow previews <iframe> and <style> content there and nothing else; the script runs once you preview, publish or export.
• Webflow says custom code takes effect in preview mode but does not go live until the site is published. The widget adds a second condition: it answers on hostnames registered for your site id, and preview is not served from your domain. The trustworthy test is a published URL on a registered domain, staging included.
• Every custom code field holds 50,000 characters: Site settings head and footer, Page settings head and before-body, and each Code Embed. A one-line loader is nowhere near that ceiling, which is why loading by src is the shape Webflow recommends.
• Do not paste <html>, <body> or <head> tags into custom code; Webflow warns that your layout will break. Every mount here is a plain div, so it never comes up.
• Newly published Webflow sites already ship jQuery 3.5.1, and Webflow warns that a second copy causes conflicts. Nothing here adds one.

A sensible first pass

1. Register the domain you publish from, plus the .webflow.io staging domain, and copy the site id.
2. Paste the loader once into Site settings, Custom code, Footer code. Save changes.
3. Add one Code Embed for the first widget, on the collection page template if it belongs on every post.
4. Publish, open the live URL, and confirm that one works before adding a second.
5. Add the rest as divs. There is no second loader, and no second subscription.

When something does not render, walk that list backward: hostname registered, site published, embed in the page rather than in the head, thread id present where the table says it belongs. Those four checks cover nearly everything. If you are still comparing hosted vendors rather than deciding what your page needs, the alternatives section has the priced comparisons.