Introduction and Architecture
|
This content was generated with the assistance of AI and should be verified against the official Webflow documentation before being relied on in production. This sub-section’s Webflow bibliography lists the reference material consulted while preparing these pages. |
This page describes Webflow as it was on 2026-10-28, the date on which its facts were checked against the official documentation. Webflow is a software-as-a-service product and has no version numbers, so everything below is dated rather than versioned; the Product Changes and Deprecations page tracks what has changed since, and Webflow publishes changes at https://webflow.com/updates and, for developers, in the developer changelog. Plans are named by tier only (Starter, Basic, Premium, Team, Enterprise, and the Ecommerce tiers); this page never quotes prices, and the Plans, Workspaces, Seats and Roles page explains which tier unlocks what. Developer tools do have versions, and the pages that use them pin them; the architecture described here needs none.
The running example of the whole sub-section is Fernbrook Gardens, a fictitious botanical garden. Its site has Home, Visit, Plants, Events, Shop, Garden Journal, About and 404 pages and a password-protected Volunteers area. This page uses it to show where each piece of the product sits: the Plants collection lives in the CMS, the visitor kiosk is a separate application that reuses Webflow components, and the Visit Planner is server code that cannot run on a Webflow page and therefore runs elsewhere.
What Webflow is
Webflow is a hosted visual web-design platform. A designer builds a site on a canvas, the Designer, by adding elements, choosing styles and defining behaviour. Webflow turns that work into real HTML, CSS and JavaScript, stores content in a built-in CMS, and serves the published result from its own hosting. There is no theme to install, no database to provision and no server to patch: the same account that holds the design also holds the content, the hosting, the forms and, if you buy them, the store and the translations.
Four properties define the product.
-
It writes standard front-end code. The output is ordinary markup, a style sheet and a small runtime script. A
divon the canvas is adivin the page, and a class in the Style panel is a class in the CSS file. This is why the sub-section can show the generated HTML and CSS next to each Designer action, and why a developer who knows the web platform can predict what the canvas will produce. See HTML and CSS in Webflow and HTML and CSS. -
It is closed and hosted. You cannot install Webflow on your own server, read its source or run a local copy. In exchange the vendor operates the platform, applies every update to every customer at once, and takes responsibility for availability and security of the hosting layer.
-
It couples design, content and hosting. In the classification used on the CMS landing page, Webflow is a SaaS CMS that is hybrid: it renders pages itself from a design and the CMS, and it also exposes the content through APIs so another application can consume it.
-
It is extensible at three levels. Designers extend it with classes, variables, components and interactions; site builders extend it with custom code in the head, the body and embeds; developers extend it with APIs, webhooks, apps, DevLink, code components, Webflow Cloud and the MCP server.
Who uses which part
Webflow is used by several kinds of people, and the product is shaped around them.
| Role in the Fernbrook team | What they do in Webflow | Where it is documented |
|---|---|---|
Site owner |
Chooses the plan, owns the workspace and the domain, decides who gets a seat |
|
Designer |
Builds pages, classes, variables, components and interactions in the Designer |
Designer Tour and the Designing section |
Content editor |
Edits text and CMS items on the canvas and publishes them |
The Content & Publishing section |
Marketer |
Manages SEO, redirects, forms, localization, analytics and tests |
The Site Settings & Operations and Commerce, Growth & AI sections |
Developer |
Syncs data with the Data API, writes custom code, builds apps, exports components, deploys Webflow Cloud apps |
The Custom Code, Data API & Headless, Apps & Extensions and DevLink, Cloud & Agents sections |
How it differs from other approaches
Webflow is often compared with three other ways of building a site. The differences are architectural, and they decide what you can and cannot do.
Against WordPress
WordPress is open-source software that you, or a host, install on a server with PHP and a database. Webflow is a service. The consequences are concrete.
| Aspect | WordPress | Webflow |
|---|---|---|
Delivery |
Software installed on a server you or a host operate |
SaaS operated by the vendor; nothing to install |
Server-side code |
PHP runs on the site’s server, in the core, themes and plugins |
No server-side code runs on a Webflow page; server logic lives in Webflow Cloud or your own backend |
Extending |
Themes and plugins that run inside the site and can change anything, including the database |
Platform features, marketplace apps that talk to the site through APIs, custom client-side code, and your own services |
Data access |
Direct database access and any plugin that adds tables |
The CMS is reached only through the Data API, the Content Delivery API, the Designer and CSV import and export |
Updates and security patches |
The site owner applies them, or a managed host does |
Applied by Webflow for everyone, with no action from the site owner |
Source control |
Theme and plugin code can live in git and deploy anywhere |
The design lives in Webflow; code that you write lives in custom code, apps, DevLink projects or Cloud apps |
Portability |
Move the files and the database to another host |
Code export of the static front end, and CSV export of CMS and Ecommerce data; features such as the CMS, forms and search do not come with an export |
The practical conclusion is that Webflow removes a whole class of operational work (patching, plugin conflicts, server tuning) and a whole class of customization (anything that needs to run on the server inside the site). A feature that WordPress delivers with a plugin that runs PHP is, in Webflow, either a platform feature, a marketplace app that calls the API, a client-side script, or a separate service that you host.
Against site builders
Hosted site builders also remove servers, but most of them constrain the output to templates and sections. Webflow gives you the CSS box model, classes, flexbox, grid and breakpoints directly, so a designer controls the layout at the level of a style sheet while never writing one. The cost is a steeper learning curve: the Designer assumes that you understand the structure of a page, the cascade and the box model, which is why the sub-section teaches the web concepts before the panels.
Against web frameworks
A framework such as React with Next.js, Laravel or Django is a library for writing an application in code. The framework comparison pages on this site (Web Frameworks Comparison and Backend Frameworks Comparison) deliberately exclude content management systems, because a CMS is a product with an editor, hosting and a content model, not a code library. Choose a framework when the product is mostly custom application logic; choose Webflow when the main job is publishing designed pages whose content people keep changing. They combine well, and several pages of this sub-section show how: a Next.js application can read the Fernbrook Journal headlessly, can reuse Webflow components through DevLink, or can run on Webflow itself through Webflow Cloud. See Next.js and React for the framework side.
The product lineup in 2026
Webflow is no longer only a Designer. As of 2026-10-28 the official product pages describe the following pieces.
| Piece | What it is | Documented in |
|---|---|---|
Designer |
The visual canvas and its panels, where pages, classes, variables, components and interactions are built; real-time collaboration and an AI assistant are part of it |
|
CMS |
Collections of structured items, bound to pages through Collection lists and template pages |
The CMS section |
Hosting |
Publishing to Webflow-operated hosting on a global edge network, with domains and automatic TLS |
|
Ecommerce |
Products, checkout, orders and inventory on top of the CMS, sold as separate site plans |
|
Localize |
Locales, localized content and translation, sold as an add-on |
|
Analyze and Optimize |
Analytics, A/B/n testing and personalization, sold as add-ons |
|
Interactions with GSAP |
The animation engine, built on a library that Webflow acquired in 2024 |
The Interactions section |
Data API v2 |
REST API for sites, pages, CMS, assets, forms, custom code, ecommerce and localization |
|
Content Delivery API |
A cached read-only API for live CMS items, intended for headless front ends |
|
Webhooks |
Event notifications from a site to your endpoint |
|
Apps |
Data Clients, Designer Extensions and hybrid apps, with the Designer API |
|
DevLink and code components |
Export Webflow components to React, and import React components into Webflow |
|
Webflow Cloud |
Hosting for full-stack applications on a serverless runtime, mounted under a site path or standalone |
|
MCP server and AI |
A Model Context Protocol server that lets AI agents work with a site, plus AI features and credits in the product |
Webflow Conf 2026 (1 to 3 September) announced further changes, among them Source by Webflow (a research preview), Releases, Agent Presence (generally available since 2026-10-21) and a breakpoint canvas. Preview features can change or disappear, so this sub-section describes them only where it says so.
How the pieces connect
The diagram below follows a change from the Designer to a visitor. It is the mental model for the rest of the sub-section.
Read it from left to right. Designers and editors change a site, which is the design plus its CMS content. Nothing reaches visitors until someone publishes. Publishing generates the HTML, CSS and JavaScript for each page and pushes them to hosting. Visitors fetch those files from the edge network. The developer surface attaches around that core: the Data API reads and writes the same site; webhooks tell your services when something happens; apps extend the Designer; DevLink moves components between Webflow and React code; Webflow Cloud runs applications beside the site; and the MCP server lets an agent use the APIs and the Designer.
Design, publish, serve
Three moments matter, and confusing them is a common source of surprises.
-
Design time. You work on the canvas. The Designer shows your pages without running most custom code, and interactions play only in preview. Comment and preview modes render on a Webflow canvas domain (a subdomain of
canvas.webflow.com), which matters when a content security policy or a domain check blocks it. -
Publish time. Webflow generates the files. A full-site publish pushes the staging domain, the custom domains you select and, for CMS content, the items that are published. Draft items are not published by a full-site publish; items can also be queued, scheduled or published individually. See Publishing and Scheduling.
-
Request time. A visitor requests a page and receives the files that publish time produced. CMS pages are generated from the published items, not computed per request from a database that the visitor can reach. The only dynamic behaviour is client-side script, a form submission handled by Webflow, a Webflow Cloud route, or a call from the page to a service of yours.
Because content and design are published together, an editor who changes a CMS item sees the change live only after publishing, and a developer who updates an item through the API makes the same distinction between the staged and the live copy of the item (see Data API: CMS).
What the published output looks like
The following is a simplified view of what a published Fernbrook page contains. The exact markup depends on the elements and settings you chose; the point is its shape: a standard document, a generated class-based style sheet, and Webflow runtime attributes and script.
<!DOCTYPE html>
<html data-wf-page="PAGE_ID_PLACEHOLDER" data-wf-site="SITE_ID_PLACEHOLDER" lang="en">
<head>
<meta charset="utf-8">
<title>Fernbrook Gardens | Visit</title>
<meta content="Opening hours, tickets and directions." name="description">
<meta content="width=device-width, initial-scale=1" name="viewport">
<link href="https://cdn.prod.website-files.com/SITE_ID_PLACEHOLDER/css/fernbrook.webflow.css" rel="stylesheet" type="text/css">
</head>
<body class="body">
<header class="section is-hero">
<div class="container">
<h1 class="heading-xl">Open every day, sunrise to dusk</h1>
<a href="/visit" class="button is-secondary w-button">Plan your visit</a>
</div>
</header>
<script src="https://cdn.prod.website-files.com/SITE_ID_PLACEHOLDER/js/webflow.js" type="text/javascript"></script>
</body>
</html>Source: Webflow: Hosting
Four details in that output are worth knowing. The data-wf-site and data-wf-page attributes identify the site and
page to Webflow’s runtime. The class w-button is a class that Webflow adds itself to elements it generates, in addition
to the classes you wrote. The style sheet is generated from the classes on the canvas, not hand written, and is served
from a content delivery network. The webflow.js script is the runtime that powers interactions, navigation bars,
sliders and tabs; code exported from Webflow therefore keeps working only if you keep that script and those attributes.
The corresponding CSS looks like ordinary CSS:
.section.is-hero {
display: flex;
min-height: 70vh;
padding: 4rem 1.5rem;
background-color: var(--brand--surface);
}
.button.is-secondary {
padding: 0.75rem 1.5rem;
border: 1px solid var(--brand--accent);
border-radius: 999px;
color: var(--brand--accent);
background-color: transparent;
}
@media screen and (max-width: 767px) {
.section.is-hero {
min-height: 50vh;
padding: 2rem 1rem;
}
}Source: Webflow: Hosting
The compound selector .section.is-hero is what a combo class compiles to; the @media block is what the tablet and
mobile breakpoints compile to. Both are covered in Classes,
Combo Classes and Selectors and Responsive Design and
Breakpoints; the cascade rules they rely on are those of Selectors and
Specificity.
What runs where
The most important architectural fact about Webflow is a boundary: no server-side code of yours runs on a Webflow page. Webflow executes its own platform code on its servers (rendering published pages, handling forms, processing checkout, serving the API), and your code runs in one of four other places.
| Where | What runs there | Typical Fernbrook use |
|---|---|---|
The visitor’s browser |
JavaScript from custom code in the head or footer, a Code Embed, an interaction, or a code component |
A script that opens the Visit page accordion, a Lottie player, a consent banner |
The Designer |
Designer Extensions: apps that run in an iframe inside the Designer and call the Designer API |
Plant Label Kit, which prints labels from the selected Plants item |
Webflow Cloud |
Full-stack applications on a serverless edge runtime, mounted under a path of the site or run standalone |
Visit Planner at |
Your own backend |
Anything that calls the Data API, receives webhooks, or serves an app |
|
This boundary has direct consequences.
-
Secrets never belong in a page. Anything in custom code is delivered to every visitor. API tokens, OAuth client secrets and webhook keys must stay in a server environment, and Webflow documents the Data API as a server-to-server API; browser calls to it are not supported. See CORS for why.
-
Dynamic behaviour needs a home. A search with relevance ranking, a signed-in dashboard, a payment flow with custom rules or a database table of your own are not Webflow page features. You either use a platform feature (site search, forms, Ecommerce), connect an app, or run the code on Webflow Cloud or your own server.
-
Cloud routes win. When a Webflow Cloud application is mounted at
/planner, a request for that path goes to the application, not to a Webflow page of the same path. -
Content flows through APIs, not SQL. There is no database to connect to. A tool that needs the Plants collection reads it through the Data API or, if it only needs live items, the Content Delivery API.
The diagram shows the same boundary as a request flow for the Fernbrook site.
Hosting, delivery and security
Publishing sends the site to hosting that Webflow operates on top of Cloudflare’s network. According to the Webflow hosting documentation, that gives every site a content delivery network, DDoS and bot protection, and TLS certificates that are issued and renewed automatically at no extra cost, so a custom domain served over HTTPS needs no certificate management by you. The hosting pages for your domain, DNS records, redirects, bandwidth and publishing options are in Domains, Hosting and Publishing Options.
Enterprise customers can additionally use custom certificates, security headers, custom hosting arrangements and a contractual availability target of 99.99 percent. Other plans do not receive that service level, so the plan you choose decides the guarantees you can promise to your own users.
Shared responsibility
A hosted platform shifts, but does not remove, security work. The split looks like this.
| Webflow is responsible for | You are responsible for |
|---|---|
Operating and patching the platform and its hosting |
Who has a seat, with which role, and removing people who leave |
Network protection, TLS and platform availability |
Two-factor authentication and strong sign-in for your team |
Isolation between customers and platform compliance |
The content you publish and the privacy of the data you collect in forms |
Rate limiting and authentication of the APIs |
Scopes, storage and rotation of the API tokens you create |
Spam filtering features of forms |
Third-party scripts you add in custom code, which run with full access to your pages |
Two privacy points from the product documentation deserve attention at the start. Custom code runs in your visitors' browsers, so every third-party script you load can see what the visitor sees; load only scripts you have reviewed and, where you can, with a subresource integrity hash. And loading fonts from Google’s font service through its API sends visitors' IP addresses to Google, which is a data-protection concern in some jurisdictions; the Help Center recommends hosting the font files yourself instead, and Typography and Fonts shows how.
Compliance and the Trust Center
Webflow publishes its security and compliance documentation at trust.webflow.com, where, as of the check date, it lists attestations such as SOC 2 Type 2 and ISO/IEC 27001. Treat the Trust Center as the source of truth: certifications, reports and sub-processors change, and the list that is current when you sign a contract is the one that matters. Reports are normally available to customers under a non-disclosure agreement, and a data processing agreement covers personal data processed on your behalf.
Credentials for developers
Developer examples in this sub-section use a Developer workspace, which is free, can hold sites that are not published to production, and has the same API rate limit as paid plans. It cannot publish to production domains, export code or transfer sites, and is capped at 1,000 visitors per month, which is ample for learning and testing. Every credential in the examples is a placeholder read from the environment, as in this request that lists the sites a token can see:
export WEBFLOW_API_TOKEN="replace-with-a-site-or-workspace-token"
curl --request GET \
--url https://api.webflow.com/v2/sites \
--header "Authorization: Bearer $WEBFLOW_API_TOKEN" \
--header "accept: application/json"Source: Data API: List Sites
A site token is created for one site with the scopes you choose, and a request with insufficient scopes fails with an error rather than returning partial data. The token workflow, scopes and OAuth are in Data API Authentication and Scopes; background on the protocol is in OAuth.
The same call from a Node and TypeScript script uses the official SDK, which wraps authentication, retries and typing:
import { WebflowClient } from "webflow-api";
const webflow = new WebflowClient({ accessToken: process.env.WEBFLOW_API_TOKEN! });
const { sites } = await webflow.sites.list();
for (const site of sites ?? []) {
console.log(site.displayName, site.shortName);
}Source: Data API: Introduction
How a site grows from a page to a platform
A useful way to read the lineup is as a ladder that Fernbrook climbs only as far as it needs.
-
A designed site. Designer and hosting only: static pages, a few forms, a custom domain. No code is needed.
-
A content site. Add the CMS: Plants, Zones, Events, the Journal and Staff become collections, and pages are templates bound to them. Editors work on the canvas.
-
A designed system. Add variables, classes with a naming convention, components and shared libraries so that many people can change the site without breaking it.
-
A behaving site. Add interactions, then custom code where the platform ends.
-
An integrated site. Add the Data API, webhooks and apps so that inventory, newsletters and internal tools stay in sync with the site.
-
A multi-surface product. Reuse components in a kiosk application through DevLink, import React components into Webflow, run an application on Webflow Cloud, serve the Journal headlessly, and give an agent access through the MCP server.
Most sites stop on the second or third rung, and that is the right place for them. The sub-section is organized in the same order, so each section assumes only the ones before it.
Where the older book is out of date
The book Webflow by Example (Packt, 2021) is a good introduction to the web concepts behind the Designer and was written for the product as it was in 2021. Its first chapter frames Webflow as a way to build sites without writing code. That framing is still true for design and content, but it is incomplete today: the platform now has a developer surface (APIs, apps, DevLink, code components, Webflow Cloud, the MCP server) that did not exist in 2021, and its commercial structure has changed. The book describes workspace and site plans under names that have since been replaced, and a content-editing tool, the Editor, that Webflow retired in 2026. The Editor timeline is on Product Changes and Deprecations, and the full list of outdated claims is on Where Older Books and Tutorials Are Outdated. Where the book and the official documentation disagree, this sub-section follows the official documentation.
Where to go next
-
To pick a plan and understand seats, read Plans, Workspaces, Seats and Roles.
-
To create a site and learn the dashboard, read First Site and the Dashboard, then Designer Tour.
-
To see how Webflow compares with WordPress and other options for a concrete project, read Comparison and Decision Guide.
-
To start developing, read Developer Platform Overview.