Embeddable builder

An embeddable drag-and-drop builder you own — for emails and pages

BuilderJS is an embeddable, framework-agnostic drag-and-drop builder library — a roughly 140KB vanilla-JS engine you mount inside your own application to give users a visual editor for both HTML emails and web/landing pages. It is the editor surface, not a platform: it produces the markup, and your app owns everything around it. BuilderJS does not send email, host or publish pages, run funnels, do CRM or automation, or process payments — you bring (or build) those parts; BuilderJS just lets people design the content. Because it is a library rather than a hosted service, it drops into React, Vue, Svelte, Angular, Next.js, Laravel, or plain HTML — any DOM node will do. Everything is JSON-first: getData() and load() give you a lossless round-trip, so the designs your users create are portable data you control. It ships dual output — modern-CSS page HTML, or Outlook-safe email HTML through an export pipeline — plus 42 element types, themes, and 20+ locales. This umbrella hub explains what an embeddable builder library is, how the one-time-license model differs from SaaS, what to look for, and where BuilderJS fits honestly.

What an embeddable builder library actually is

An embeddable builder library is a visual drag-and-drop editor delivered as code you install into your own product, rather than a website you log in to. You import it, mount it in a DOM node, and your users get a what-you-see-is-what-you-get canvas for laying out blocks, columns, text, images, and buttons. The library's job ends at the markup boundary: it gives you structured design data (here, JSON) and rendered output (HTML), and your application decides what to do next — store it, send it, render it, publish it. That separation is the whole point. A SaaS editor couples the editing experience to one vendor's hosting, sending, and billing; a library hands you the editing experience and leaves the rest to you. BuilderJS sits squarely in this category: a ~140KB engine with 42 element types, 59 property controls, and 31 canvas overlays, framework-agnostic by design, that builds both email templates and web pages from the same JSON model.

Why one-time licensing differs from SaaS

Most embedded editors are sold as monthly SaaS. For example, Unlayer's embeddable builder is free at entry, then Launch is $250/mo, Scale $750/mo, and Optimize $2,000/mo (as of June 2026, source: unlayer.com/pricing) — recurring, and the engine runs on the vendor's terms. The other end of the spectrum is open source: GrapesJS is BSD-3-Clause and free (as of June 2026, source: github.com/GrapesJS/grapesjs), but you self-assemble email-safe export, polish, and support yourself. BuilderJS takes a third path: a one-time CodeCanyon license (item 27146783) — Regular $52 / Extended $99 — where you buy once, own the source, and self-host. There is no monthly fee, no per-seat charge, no usage metering, and no phone-home. CodeCanyon's model is itself one-time per license tier (as of June 2026, source: codecanyon.net/licenses/standard). The trade-off is honest: author support is time-boxed (roughly 6–12 months), so you are buying source you own, not an open-ended support contract.

What to look for in a builder library

Five things separate a library you can ship from one that becomes a maintenance burden. First, framework fit: it should mount in whatever you already use — React, Vue, Svelte, Angular, Next.js, Laravel, plain HTML — without a rewrite. Second, output portability: a JSON-first model with a lossless round-trip (getData()/load()) means designs are your data, not a vendor lock-in format. Third, email correctness if you need it — turning a modern-CSS layout into Outlook-safe HTML is genuinely hard, so look for a real export pipeline (table conversion, SVG-to-PNG, mobile-stack media queries, MSO conditionals, CSS inlining) rather than a naive HTML dump. Fourth, extensibility without forking: custom elements, widgets, controls, themes, and i18n should be registration APIs, not patches to core. Fifth, honest scope: confirm what the library does not do — most do not send, host, or publish — so you plan the surrounding plumbing up front. BuilderJS is built to satisfy all five.

How BuilderJS fits — honestly

BuilderJS is the editor you embed; your application is the platform. It builds the template and the markup; you bring the sending, hosting, and publishing. Concretely: for email, it produces Outlook-safe HTML via the EmailExportPipeline (flexbox-to-table, SVG-to-PNG, @media mobile-stack, MSO conditionals, CSS inliner), Litmus-tested across 22 clients — but you connect your own ESP or SMTP to actually deliver it. For pages, it emits modern-CSS HTML — but you host and serve it. It is multi-tenant capable through closure-captured instances, yet your app still owns tenant isolation, seats, and billing. It exposes pluggable, vendor-neutral AI hooks, but does not bundle a model. It ships reference PHP backends (MySQL/SQLite/S3 for save, upload, auth, realtime) that you copy and own, and can port to Node, Go, or Python. In short: BuilderJS gives users an embedded design experience inside your product; everything after "export" is yours to wire up.

At a glance — the builder library categories

This hub routes down to focused spokes. For email specifically, the self-hosted email builder covers the export pipeline, client testing, and template library. For web and landing pages, the self-hosted page builder explains modern-CSS output and the host-it-yourself caveat. The block-editor library page details the 42 element types, controls, and canvas overlays. The white-label builder page covers theming and i18n so the editor looks like your product, not a third party's. The one-time-license page breaks down Regular vs Extended and what "own the source" really means. The JSON-builder page documents the getData()/load() round-trip and the portable data model. The alternatives page compares the library, SaaS, and open-source approaches neutrally. And the embed page is the practical how-to for mounting BuilderJS in any framework. Start with whichever matches your use case; each links back here.

Explore

Frequently asked questions