Guides: email & page builder concepts

Why email and web pages are not the same build problem

A web page is rendered by a browser. Browsers are modern, forgiving, and largely agree on how CSS works, so you can keep styles in a stylesheet and trust the result. Email is rendered by dozens of clients — Outlook on Windows, Gmail's web app, Apple Mail, mobile apps — and many of them strip out stylesheets, ignore modern layout, or wrap your code in their own quirks. That is why robust email markup leans on tables, inline styles, and fallbacks that look dated next to a normal web page. The practical upshot: a single design often needs two different outputs. BuilderJS addresses this with dual export — it produces standard page HTML, or runs an email export pipeline that converts flexbox to tables, SVG to PNG, adds mobile-stacking media queries, MSO conditionals for Outlook, and inlines CSS for client compatibility. Understanding this split is the foundation for the inline-CSS and JSON guides below.

Inline CSS for email, in plain terms

Inline CSS means writing styles directly on each element — style="color:#111;font-size:16px" — instead of in a separate stylesheet or a <style> block in the page head. On the web you almost never do this by hand; it is tedious and hard to maintain. For email it is often a survival tactic, because several major clients discard <style> blocks before the message is shown, leaving any non-inlined rule with nothing to apply. The fix is an inliner: a step that reads your stylesheet and copies the matching rules onto each element automatically, so you author in a sane way but ship inlined output. A good builder hides this entirely — you style visually, and inlining happens at export. BuilderJS does exactly this: its email export pipeline runs a CSS inliner so the markup you build survives clients that strip stylesheets. Our dedicated guide walks through which clients strip styles, what an inliner does step by step, and where the technique still has limits worth knowing before you rely on it.

JSON templates versus raw HTML

When you save a design, it can be stored two ways. Raw HTML saves the final markup — what the browser or email client will render. JSON saves a structured description of the design: a tree of elements, their settings, and their content, separate from the rendered output. The difference matters for editing. Re-opening raw HTML in a visual editor is lossy and fragile, because the editor has to guess your intent from finished markup. Re-opening JSON is lossless: the editor reads back the exact structure you saved. BuilderJS is JSON-first — getData() exports the design as JSON and load() restores it with a faithful round-trip, then it generates HTML (page or email) from that JSON on demand. This is why JSON-backed builders handle versioning, duplication, and re-editing cleanly. The guide explains the trade-offs: JSON is great for editing and storage, while HTML is the rendered output your own sending or hosting layer ultimately uses.

Embeddable versus standalone builders

A standalone builder is a product you log into — a hosted app with its own account system, where your designs live on the vendor's servers. An embeddable builder is a component you mount inside software you already own, so the editor appears as part of your app and you control where the data goes. The choice is mostly about ownership. Standalone is fast to start and requires no engineering, but you rent the workflow and your templates sit in someone else's account. Embeddable means you wire it into your own product, your own UI, and your own backend — more setup, far more control. BuilderJS is the embeddable kind: a roughly 140KB DOM-mount bundle (dist/builder.js + dist/builder.css) that drops into React, Vue, Svelte, Angular, Next.js, Laravel, or plain HTML, with reference PHP backends you copy and own (and can port to Node, Go, or Python). The guide breaks down which model fits which team, and what 'self-hosted' really commits you to.

How these concepts connect — and where BuilderJS fits

These ideas stack. You choose embeddable or standalone first, because that decides who owns the data and the workflow. If you go embeddable, JSON-first storage becomes the practical default, because your app needs a clean format to save, version, and re-edit designs. And if you build email at all, inline CSS and an export pipeline are non-negotiable, because the design that looks right in the editor must survive Outlook and Gmail. BuilderJS sits at the intersection: an embeddable, framework-agnostic library that stores designs as JSON and exports either page HTML or Outlook-safe email HTML. For context, finished, supported, framework-agnostic open-source projects exist too — GrapesJS is BSD-3-Clause-licensed and MJML is MIT-licensed, both free and actively maintained (as of June 2026; see github.com/GrapesJS/grapesjs and github.com/mjmlio/mjml). Each builds template markup in its own way; the right pick depends on whether you want a hosted app, a free framework, or an owned, embeddable editor that builds both email and pages. The guides below help you decide on the concepts first, vendor second.

Frequently asked questions

• Does BuilderJS send my emails or publish my pages? expand_more

  No. BuilderJS is the editor you embed, not a platform. It builds the template and produces HTML — page HTML or Outlook-safe email HTML — and exports the design as JSON. Sending email, hosting pages, ESP integration, and publishing are entirely your app's job; you bring your own sending and hosting.

• Why does email need inline CSS when web pages don't? expand_more

  Several major email clients strip out <style> blocks and external stylesheets before showing a message, so any non-inlined rule has nothing to apply. Writing styles directly on each element (inline CSS) survives that stripping. Web browsers keep stylesheets intact, so the web rarely needs it. An inliner automates the conversion at export time — BuilderJS does this in its email export pipeline.

• What's the practical difference between storing a design as JSON or HTML? expand_more

  JSON stores a structured description of the design — the element tree and its settings — which an editor can re-open losslessly for further editing. HTML stores the finished, rendered markup, which is what your sending or hosting layer uses but is fragile to re-edit visually. JSON-first tools like BuilderJS keep both: JSON for editing and storage, generated HTML for output.

• What does 'embeddable' mean compared to a standalone builder? expand_more

  A standalone builder is a hosted app you log into, where designs live on the vendor's servers. An embeddable builder is a component you mount inside software you already own, so you control the UI and where data is stored. BuilderJS is embeddable — a ~140KB DOM-mount bundle that mounts in React, Vue, Angular, Svelte, Next.js, Laravel, or plain HTML.

• Are there free, open-source alternatives to a paid builder? expand_more

  Yes. GrapesJS (BSD-3-Clause) and MJML (MIT) are both free and actively maintained as of June 2026 — see github.com/GrapesJS/grapesjs and github.com/mjmlio/mjml. They are finished, supported, framework-agnostic options. The right choice depends on whether you want a hosted app, a free framework, or an owned embeddable editor that builds both email and web pages.

• Do I need to be a developer to use these concepts? expand_more

  To understand them, no — that is what these plain-English guides are for. To use an embeddable builder like BuilderJS in production, yes: you mount it client-side in your own app and wire getData() output to your own backend route. Standalone hosted tools require no engineering but trade away ownership and control.