BuilderJS

An Embeddable Drag-and-Drop Page Builder for Your App

If your roadmap has "let users design their own pages" on it, you already know the trap: a visual editor is three to six months of drag handles, undo stacks, responsive controls, image uploads, and serialization — work that has nothing to do with your actual product. BuilderJS is the part you were about to rebuild. It's an embeddable drag-and-drop page builder you mount into any DOM node — React, Vue, Svelte, Angular, Next.js, Laravel, or plain HTML — as a roughly 140KB vanilla-JS bundle. It ships 42 element types, 59 controls, and 31 overlays out of the box, and it's JSON-first: getData() and load() give you a lossless round-trip you store wherever you like. It builds both web/landing-page HTML and Outlook-safe email HTML from the same canvas. You buy it once on CodeCanyon, get the source, and self-host it. No SaaS dependency, no per-seat billing, no usage meter phoning home. The editor lives in your app, on your terms.

Mount it where your app already lives

BuilderJS is framework-agnostic by design: it's a DOM-mount bundle (dist/builder.js + dist/builder.css), not a published npm React or Vue component. You hand it an empty element and it takes over from there. In React you initialize it inside a useEffect; in Vue inside onMounted; in Angular inside ngAfterViewInit; in Svelte inside onMount. It runs client-side only, so in Next.js you load it with a dynamic import using ssr:false and a 'use client' directive. Persisting a design is deliberately boring — and that's the point: call getData() to get the JSON, POST it to your own route or backend, and call load() to bring it back. Because the editor is closure-captured, there's no global state to leak between tenants. BuilderJS is multi-tenant capable, but your application keeps owning tenant isolation, seats, and billing — which is exactly where that logic belongs.

One editor, two outputs: pages and email

Most teams discover they need both a landing-page builder and an email designer, then bolt on a second tool. BuilderJS produces both from one canvas. For web, it emits clean page HTML. For email, the EmailExportPipeline converts your design into Outlook-safe markup: flexbox layouts become tables, SVGs are rasterized to PNG, @media rules stack columns on mobile, and MSO conditional comments plus a CSS inliner handle the rendering quirks that make email HTML notoriously painful. To prove it, the library ships 30+ templates and 200+ samples that have been Litmus-tested across 22 email clients. Worth stating plainly: BuilderJS builds the email markup — it does not send it. You bring your own ESP or SMTP for delivery. Same for pages: BuilderJS produces the HTML; your app handles hosting and publishing.

Extend it without forking

A builder you can't customize becomes a liability the first time a customer asks for something it doesn't do. BuilderJS is built to be extended without touching its source: register your own custom Elements, Widgets, and Controls through Builder.registerElement, drop in custom themes, and localize the UI with i18n across 20+ locales including RTL. If your product has AI features, the builder exposes pluggable, vendor-neutral AI hooks — you wire in whichever model you use, rather than being locked to one. Because you own the source from your CodeCanyon purchase, nothing about this depends on a vendor shipping the feature you need. You can read it, patch it, and ship it on your schedule.

Own the source — no metered SaaS in your critical path

The honest comparison here is with the embeddable-editor market, not with end-user platforms. GrapesJS, the well-known open-source builder framework, is free under the BSD-3-Clause license (per github.com/GrapesJS/grapesjs, as of June 2026) — but free and finished are not the same thing, and assembling a complete, supported, framework-agnostic editor that builds both email and pages from its primitives is the very three-to-six-month effort you're trying to avoid, which is why its own team now offers the commercial Studio SDK. That SDK is session-metered SaaS: a free tier at $0/month capped at 1,000 sessions with Studio branding ($50 per extra 1,000 sessions), then Startup at $200/month (20,000 sessions, $20 per extra 1,000) and Business at $2,000/month (50,000 sessions, $10 per extra 1,000), per grapesjs.com/sdk/pricing as of June 2026. BuilderJS takes the opposite stance: a one-time CodeCanyon license (item 27146783, Regular $52 / Extended $99) for the source, which you self-host. No monthly fee, no per-seat charge, no session metering, no phone-home. The trade-off is honest: author support is time-boxed (roughly 6–12 months), so you're buying source you own and maintain — not an ongoing managed service.

What you actually ship versus what you build

Embedding BuilderJS reframes the work. The editor canvas, drag-and-drop, the 42 elements and 59 controls, undo/redo, responsive editing, the lossless JSON model, and the dual page/email export are done. What stays yours — and should — is the surrounding product: authentication, where designs are stored, how tenants and seats are organized, and how finished output gets used downstream. To make that wiring concrete, BuilderJS includes reference PHP backends (MySQL/SQLite/S3 for save, upload, and auth) that you copy and own outright; if your stack is Node, Go, or Python, they're a clear blueprint to port. You can try the editor itself at the live demo, builder.emotsy.com, before you write a single line of integration code.

Frequently asked questions

Explore