Examples
35 working examples. Pick your path.
Real code, no pseudocode. Every example renders inside the page so you see it work before you copy it.
Showing 35 of 35 examples.
Basic Basic 5 examples
Buyer's first 5 minutes. Drop-in integration, theme registration, dark mode, multi-instance.
Five minutes from "git clone" to a live canvas. Drop-in integration, theme registration, dark mode, multi-instance.
Basic FEATURED · START HERE#1 · Quick Start
Five lines of HTML + JS — your users get a full drag-drop builder in under a minute.
BUYER-JOURNEY PATH Walk this with the Get Builder running in 5 minutes path-
Basic
#1 · Quick Start
Five lines of HTML + JS — your users get a full drag-drop builder in under a minute.
-
Basic
#2 · Hello World
Click Save and watch JSON round-trip to disk. Same builder as Quick Start, plus a 30-line PSR-12 backend that you can swap for any database.
-
Basic
#3 · Custom Theme
The directory layout BuilderJS reads. Fork themes/default/, change the brand block, edit one or two templates — every page across your product picks it up.
-
Basic
#4 · Light & Dark Mode
One cookie shared across host page + builder canvas. Buyers get a system-preference default, a manual toggle, and a builder canvas that follows for free via CSS cascade — no JS bridge.
-
Basic
#5 · Multi-page
Drop multiple Builder instances on one host page — header, body, footer side-by-side. Each carries its own JSON state; events stay scoped to the instance that emitted them.
Backend Backend 4 examples
Wire any backend in ~20 lines. PDO + SQLite fallback so it boots zero-config.
Wire any backend in ~20 lines. PDO + SQLite fallback so it boots zero-config; swap drivers when you ship.
Backend FEATURED · START HERE#1 · Save to MySQL
PDO + prepared statements with a SQLite fallback so it boots zero-config. One driver swap and the same handler talks to MySQL, MariaDB, or PostgreSQL.
BUYER-JOURNEY PATH Walk this with the Production stack — multi-tenant + auth + storage path-
Backend
#1 · Save to MySQL
PDO + prepared statements with a SQLite fallback so it boots zero-config. One driver swap and the same handler talks to MySQL, MariaDB, or PostgreSQL.
-
Backend
#2 · Save Assets to S3
Stream uploaded images to any S3-compatible store. Ships with a one-command MinIO docker-compose so dev runs without an AWS account.
-
Backend
#3 · Session Auth
Multi-user save flow scoped per session. Defaults to a flat
users.jsondriver — swap one line for PDO when you go to production. -
Backend
#4 · Realtime Sync
Multi-tab live sync over a tiny PHP polling endpoint. Swap one function for Pusher / Ably / WebSocket without touching the save side.
Cookbook Cookbook 8 examples
8 ready-to-paste chrome shapes. Each entry is 4 self-contained files — copy the dir verbatim into your project.
Eight ready-to-paste chrome shapes. Each entry is four self-contained files — copy the dir verbatim into your project.
Cookbook FEATURED · START HERE#4 · Rich 3-col + header — full SaaS chrome
Three sub-systems wired (widgets · canvas · settings) plus an in-wrapper 48 px header strip carrying Save / Undo / Redo / Export / Preview. First cookbook entry where action buttons live INSIDE the engine's wrapper, not in a host toolbar above it. Pick this when your host app delegates the whole top-of-editor area to BuilderJS.
BUYER-JOURNEY PATH Walk this with the Match the Builder to your app's UI path-
Cookbook
#1 · Minimal — canvas + thin top strip
No widgets palette, no settings sidebar — just a 36 px header strip for a title or a Save button, and the editing canvas. Pick this when your host app already supplies the chrome.
-
Cookbook
#2 · Compact 2-col — canvas + right Settings
Read-mostly editor: text and colours come from the right-side Settings panel; no widgets palette. Pick this when content is authored elsewhere (CMS, AI, copy team) and the buyer's job is just polish.
-
Cookbook
#3 · Compact 3-col — widgets + canvas + settings
Classic app-chrome at 1024 px+. Drag from the left widget palette, edit on the canvas, polish on the right Settings panel. Tighter than the full demo builder — narrower 200 px / 240 px sidebars leave more canvas room for embed in a denser host app.
-
Cookbook
#4 · Rich 3-col + header — full SaaS chrome
Three sub-systems wired (widgets · canvas · settings) plus an in-wrapper 48 px header strip carrying Save / Undo / Redo / Export / Preview. First cookbook entry where action buttons live INSIDE the engine's wrapper, not in a host toolbar above it. Pick this when your host app delegates the whole top-of-editor area to BuilderJS.
-
Cookbook
#5 · Sidebar only — floating Settings overlay
Canvas takes the full wrapper; Settings floats absolutely top-right with shadow + rounded corners. No widgets palette, no inline sidebar — "edit in place" feel for host pages where the canvas is primarily a viewer and edits are occasional. Click any canvas element → settings appear in the floating panel; click another → settings re-render. Same engine, different chrome silhouette.
-
Cookbook
#6 · Canvas only — no chrome, programmatic-edit only
No widgets palette. No settings panel. No header. The wrapper has no border, no radius, no background — just the canvas. Every action — selection, mode toggle, save — comes from a method on
builder. Pick this when your host app drives mutations programmatically (server-side AI generator, headless test rig, integration suite) or when the host already paints its own chrome around the canvas. -
Cookbook
#7 · Mobile — tab-based chrome (Widgets / Canvas / Settings)
Phone-friendly chrome: a top tab strip swaps which sub-system fills the body. All three sub-systems are mounted (no null args) — only ONE is visible at a time, driven by the wrapper's
data-mobile-tabattribute. Pick this when canvas + sidebars don't fit side-by-side at narrow viewports (375 px – 600 px), or when buyers prefer a tap-one-at-a-time flow over juggling 3 columns. Same engine, same API, different chrome geometry. -
Cookbook
#8 · Card — dashboard tile (360 × 420 fixed)
Builder embedded as a small card alongside other dashboard widgets. Fixed
360 × 420footprint + rounded corners + drop shadow — the only cookbook variant with explicit pixel dimensions. DOUBLE null-arg pattern (no widgets palette, no settings sidebar): the card has room for a 40-px header + canvas only. Pick this when the Builder is one of N tiles on a dashboard, not the page-defining feature.
Events Events 5 examples
React to engine state changes — document saved, element added, mode flipped, region focused.
Subscribe to engine state changes — document:changed, element:added/removed, history:change, mode:changed, region:focus.
#4 · Save click — custom button + 4-state status pipeline
Wire any host-side button to `builder.save()` and surface the full saving lifecycle (idle → saving → saved → error → retry). No engine `save:click` event — the pattern is imperative: button click → save Promise → state pill update.
-
Events
#1 · document:changed — last-modified pill
Subscribe to the engine's `document:changed` event and update a host-side pill on every edit. The bus debounces internally at 120 ms — one host-visible signal per typing burst, not per keystroke.
-
Events
#2 · element:added / element:removed — live activity log
Subscribe to both element:added and element:removed on the same bus, render a bounded list of the last N mutations. Each event carries { elementUid, elementType } — enough to identify what changed without serializing the page tree.
-
Events
#3 · history:change — external Undo/Redo buttons
Subscribe to history:change and drive your own Undo/Redo buttons OUTSIDE the engine chrome. The payload carries { canUndo, canRedo, size, currentIndex } — enough to drive button state and a "step N of M" pill from a single signal.
-
Events
#4 · Save click — custom button + 4-state status pipeline
Wire any host-side button to `builder.save()` and surface the full saving lifecycle (idle → saving → saved → error → retry). No engine `save:click` event — the pattern is imperative: button click → save Promise → state pill update.
-
Events
#5 · region:focus / region:blur — focused-region indicator
Subscribe to region:focus / region:blur and surface the currently-focused padding side as a live status strip. Both events fire from the PaddingMarginControl (settings panel) — payload carries { elementUid, namespace, regionKey } so a host can scope autosave or undo behaviour to the active region.
API API 5 examples
Programmatic operations — getHtml, getData, setMode, selectElement, clearElements.
Programmatic operations — getHtml(), getData(), setMode(), selectElement(), structural mutation via load().
#1 · getHtml() + getHtmlWithRelativeLinks() — HTML export
Two flavours of HTML export from one engine surface. getHtml() returns the canvas with absolute media URLs (themeMediaUrl prefix included); getHtmlWithRelativeLinks() strips that prefix so the saved HTML is portable across domains. Side-by-side preview + Download .html link.
-
API
#1 · getHtml() + getHtmlWithRelativeLinks() — HTML export
Two flavours of HTML export from one engine surface. getHtml() returns the canvas with absolute media URLs (themeMediaUrl prefix included); getHtmlWithRelativeLinks() strips that prefix so the saved HTML is portable across domains. Side-by-side preview + Download .html link.
-
API
#2 · getData() + load() — copy state between two Builders
Two side-by-side Builders A and B share theme + templates but render independent JSON state. One button calls A.getData() → B.load(...) and the page tree teleports. Symmetrical contract: whatever getData returns, load consumes.
-
API
#3 · setMode() + MODE_CHANGED — design / preview toggle
Two API calls (`setMode('design')` · `setMode('preview')`) plus the `MODE_CHANGED` event subscriber give you a segmented toggle that stays in sync with the engine. Click handlers fire the API; the event listener is the single source of truth for the UI state.
-
API
#4 · selectElement() + unselect() — programmatic selection from a custom outline
Render your own outline sidebar and call `builder.selectElement(block)` to select programmatically. The engine paints the canvas selection rectangle, opens the settings panel, and fires every internal hook the same way a click-to-select does. `builder.unselect()` clears.
-
API
#5 · clear() + load() + getData round-trip — wipe, reset, insert
Three structural API operations. `builder.clear()` empties the page (undoable in one step). `builder.load(SEED, ...)` replaces the tree with a known-good snapshot. The `getData() → mutate → load()` round-trip is the canonical pattern for programmatic insertion / reorder / splice / AI-replace.
Extensions Extensions 5 examples
Extend the engine — custom widgets, custom elements, custom controls, locale packs.
Extend the engine — custom widgets, custom elements, custom controls, locale packs, multi-tenant by closure capture.
Extensions FEATURED · START HERE#1 · Custom Widget — subclass BaseWidget, register, ship
Three engine touchpoints — `extends BaseWidget` (with `getName` / `getIcon` + a constructor that builds `this.block`), `widgetsBox.addWidget(new MyWidget(), { group })`, and `widgetsBox.render()`. Custom palette items drag onto the canvas the same way stock widgets do; child elements become inline-editable from first drop.
BUYER-JOURNEY PATH Walk this with the Add custom widgets, elements, and controls path-
Extensions
#1 · Custom Widget — subclass BaseWidget, register, ship
Three engine touchpoints — `extends BaseWidget` (with `getName` / `getIcon` + a constructor that builds `this.block`), `widgetsBox.addWidget(new MyWidget(), { group })`, and `widgetsBox.render()`. Custom palette items drag onto the canvas the same way stock widgets do; child elements become inline-editable from first drop.
-
Extensions
#2 · Custom Element — extend BaseElement, register, save/load round-trip
Three engine touchpoints — `extends BaseElement` (with `static parse(data)` + `getData()` + `_doRender()`), `Builder.registerElement(name, klass)` (mutates the registry, exposes the class on `window.*`), and a one-line EJS template injection into `builder.templates`. After registration, JSON nodes carrying `{ "name": "CountdownElement", … }` parse + render through the SAME path stock elements use.
-
Extensions
#3 · Custom Control — extend ColorPickerControl with brand swatches, wire via getControls()
Three engine touchpoints — subclass an existing `ColorPickerControl` (override `render()` to add brand swatches), instantiate inside a custom Element's `getControls()` (the engine auto-wires the panel on click), and route swatch clicks through `_notify(hex)` (the same callback path the hex input uses). Controls aren't registry-based today; coupling them to an Element via `getControls()` is the canonical buyer-side path.
-
Extensions
#4 · i18n Locale Pack — I18n.init() + locale switcher with builder re-render
One engine touchpoint — `I18n.init(messages)` replaces the active messages dictionary wholesale; `I18n.t(key)` falls back to compile-time `en.json` defaults for any key the active dict misses. The buyer owns the re-render call after locale switch (the engine doesn't auto-repaint when messages change).
-
Extensions
#5 · Multi-tenant SaaS — closure-captured tenantId per Builder
Two side-by-side editors share ONE engine bundle but are fully isolated by tenant. Asset browses + saves route through tenant-scoped URLs via closure-captured `tenantId` in the constructor; the engine itself stays tenant-naive (zero `src/` change). Backend `_lib/TenantRegistry.php` answers "what is this tenant allowed to access?" — listForTenant / assetRootFor / saveDirFor.
Flows Flows 3 examples
End-to-end production patterns — bundle export, bundle import, history shortcuts.
End-to-end production patterns — bundle export round-trip, drag-drop import, history chord ladder.
Flows FEATURED · START HERE#1 · Export HTML / ZIP / Bundle — three modes, one engine read
One pair of engine reads — `getHtml()` (absolute URLs) + `getHtmlWithRelativeLinks()` (relative URLs) — feeds three backend endpoints that ship three different artefacts. HTML for in-editor consumers, ZIP for cross-domain hosting, Bundle for cross-tenant migration. The buyer wires three buttons; the engine + backend do the rest.
-
Flows
#1 · Export HTML / ZIP / Bundle — three modes, one engine read
One pair of engine reads — `getHtml()` (absolute URLs) + `getHtmlWithRelativeLinks()` (relative URLs) — feeds three backend endpoints that ship three different artefacts. HTML for in-editor consumers, ZIP for cross-domain hosting, Bundle for cross-tenant migration. The buyer wires three buttons; the engine + backend do the rest.
-
Flows
#2 · Import saved page — drag-drop .json → builder.load() round-trip
The symmetric pair to W6.C.15 export. Save the canvas as a `.json` blob via `getData()`, drag it back onto the canvas to re-hydrate via `builder.load()`. No JSZip dependency — pure native FileReader + JSON.parse + the canonical 4-arg `load()` signature.
-
Flows
#3 · History keyboard shortcuts — chord ladder + max-history stepper
Three layers in 30 lines of buyer code: (1) the engine wires Cmd-Z / Cmd-Shift-Z / Cmd-Y for free, (2) extend the ladder with any custom chord (Cmd-Shift-Backspace = rewind to start), (3) flip the stack ceiling on the fly via `history.maxSize`. Reactive Undo/Redo + step counter all driven by the `history:change` listener — single source of truth.
No examples match your filters
Try clearing the search box or picking a different tier. Every example is one click away.