Webflow Release Notes

With the Algolia Search and Sync app, you can connect Webflow to your Algolia account and create a fast, polished search experience without writing or maintaining custom code.

Building a custom site search experience can be tedious and even harder to maintain as your CMS content grows. Now, with the Algolia Search and Sync app, you can connect Webflow to your Algolia account and create a fast, polished search experience without writing or maintaining custom code.

Here’s what you can expect

• Create richer search experiences: Add refinement lists, range filters, toggles, sorting, and Algolia Recommend units to the elements you design, so visitors can find the most relevant content faster.
• Build flexibly in the Webflow canvas: Design your search interface directly in Webflow and use the Algolia app to apply attributes to power the front-end experience.
• Map once, sync automatically: Choose a CMS collection, map its fields to your Algolia index, and let published changes sync automatically. Your search results stay current without having to manually manage the index.

The app is free to install and available to all Webflow users.

Learn more:

• Install Algolia Search and Sync
• Help Center Article

New tools

MCP v2.1 introduces three new tools that open up areas of Webflow the MCP server couldn't reach before: Interactions with GSAP, Webflow Cloud, and Campaigns.

Interactions with GSAP

Agents can now bring pages to life with motion and interactivity. Interactions with GSAP is Webflow's visual animation tool, built on GSAP, the popular open source animation library, and MCP v2.1 opens it to agents for the first time. You keep complete authoring control over the result: an agent makes the first pass, and you tweak the details on the timeline and in the visual editor. Agents can now:

• Create an interaction from a complete definition, its triggers and its timelines, in a single call.
• Animate on click, hover, page load, scroll, mouse move, and custom events.
• Update an existing interaction, or remove one.
• List a site's interactions and read one with its timelines resolved.

Webflow Cloud

Agents can now take a broken deployment from error to fix without leaving the editor you work in. Webflow Cloud is Webflow's platform for building and hosting full-stack applications, and MCP v2.1 brings its apps, environments, and deployments into reach. An agent can read a failing build's logs, make the change, and redeploy, instead of you moving between the command line and the dashboard. Agents can now:

• Create, list, and inspect apps built from a GitHub repository, change an app's name, description, or source, and archive or permanently delete one.
• Set up environments that map a Git branch to a mount point on the app, then list, update, or delete them.
• Deploy the connected branch's latest commit, or redeploy an earlier deployment's exact commit to retry a failure or roll back.
• Track deployments by status, commit, build timings, build size, and framework, listed newest first.
• Read build and runtime logs to find out why a deploy failed or what an app is doing in production.
• List environment variables, which return values for non-secret entries only, and delete one by key.
• List the custom domains the app's site serves on.
• Preview a destructive or deploy action with a dry run before committing to it, and pass an idempotency key so a retried call does not deploy twice.

Campaigns

Agents can now help marketers get a campaign out the door. Campaigns is Webflow's new standalone tool for demand gen and performance marketers to create, launch, and measure on-brand campaigns with fewer handoffs, and MCP v2.1 opens it to agents from the start. An agent can turn a brief into a landing page, build personalized variations for each audience, and report on what the campaign did. Agents can now:

• Find the sites in a workspace that have Campaigns enabled, and list the campaigns on one.
• Create a campaign and its landing page from a markdown brief. The page generates in the background, and a task status action reports when it is finished.
• Read and update a campaign's name and brief, which does not regenerate the landing page, or delete a campaign along with its landing page record and generated assets.
• Create page variations from suggested audiences or from your own name, slug, and summary, then update up to 30 of them in a single call.
• Personalize an element setting or a component instance prop by creating a campaign field bound to it, then rename that field or remove it across every variation.
• Measure a campaign by daily sessions, users, or pageviews, form submission counts, the companies that engaged, and CRM opportunity totals for open and closed-won deals.

Updates on existing tools

Two tools already in the server gained new actions or capabilities in v2.1:

• data_pages_tool adds the rest of the branch lifecycle. Alongside creating, listing, reading, and deleting branches, agents can now pull the latest changes from a site's main pages into a branch (update_branch), merge a branch back into main (merge_branch), publish a branch's preview to its staging domain (publish_branch), and read a branch's unresolved conflicts without attempting a merge (get_branch_conflicts). Branch actions require the site's workspace to be on an Enterprise plan, and the mutations run asynchronously, returning a task ID to poll with get_branch_task_status.
• data_cms_tool adds field groups and richer item queries. Agents can now read a collection's field groups along with the fields eligible for grouping (get_collection_field_groups), and replace the full ordered set (update_collection_field_groups) — a collection holds up to 50 groups, and field groups are not available on Ecommerce collections. list_collection_items can also filter and sort on custom fields: filter with bracket notation (filter[price][gte]=10), with operators that vary by field type (eq, ne, in, nin, gt/gte/lt/lte on numbers and dates, contains/ncontains on text, and exists everywhere), and sort with sort[price]=desc on sortable field types. A request allows up to 10 filter terms and 3 sort fields.

Agent instructions

Agents can now write the guidance they work from. In v2.0, agents could search, read, create, update, move, and delete a site's rules and skills. MCP v2.1 adds generation, so an agent can produce an instruction from the site itself.

Four types can be generated: brand guidelines, design system, asset guidelines, and CMS guidelines. The first three read the current Webflow site by default and can take one public URL as supplementary evidence, which helps when the brand lives on a marketing site hosted elsewhere. CMS guidelines read a specific collection instead, and take no supplementary source.

Generation runs asynchronously: the first call returns a task ID, and the same action polls it until the job finishes or fails, at which point the result carries the draft's path and resource URI. Starting a generation needs agent_instructions:write, while polling needs only agent_instructions:read. Every generated instruction is saved as a draft, so review it before treating it as durable site guidance, since once in place it becomes context that every agent working on that site reads.

Generating an instruction consumes AI credits; polling does not. The credits are spent by the Webflow agents that analyze the site or collection and draft the instruction — the task status check is a plain read.

Migrating from an earlier version

Nothing to do if you are already on v2.0.1. No tool or action names changed in v2.1, so skills, prompts, and automations written against 2.0.1 keep resolving, and everything in this release is additive.

Known limitations

A few limitations to be aware of in this release:

• Interactions with GSAP only. Agents cannot see or edit Classic interactions. On a site that uses Classic, asking an agent for a site's interactions returns an empty result, which looks the same as a site that has none. An agent can still add an interaction there, which leaves the site running both versions but carries a performance cost. The Interactions panel shows one version at a time, so switch the version dropdown at the bottom of the panel to Interactions with GSAP to see what an agent created.
• Webflow Cloud keeps secrets out of MCP. Environment variable values cannot be set through MCP, and listing variables returns values for non-secret entries only. Set variables with the Webflow CLI. Deployment through MCP works only on apps connected to a GitHub repository. Build and runtime logs are returned unsanitized and may contain secrets.
• Campaigns is in Early Access. The Campaigns tool works only on sites in the Early Access program. It covers building and measuring rather than launching: connecting marketing forms and pushing assets to ad platforms stay in the Campaigns interface. A published page variation cannot be deleted, and deleting a campaign permanently removes its landing page record and its generated assets.
• Element snapshots still require the bridge app.element_snapshot_tool captures a visual snapshot of an element, letting an agent understand the current state of a site and verify its own changes without publishing. This still depends on a live Designer session via the Webflow MCP Bridge App. We're working to make it headless, and until then we recommend letting the agent publish to a staging domain, which unlocks full agent loops that can run independently of the Designer.
• Custom fonts don't cover remotely hosted Google or Adobe Fonts.data_fonts_tool manages a site's uploaded font files only. Remotely hosted Google and Adobe Fonts must still be managed manually in site settings. For Google Fonts, you can download the font files locally and then upload and manage them through the MCP server.
• Some uploads require direct access to Amazon S3. Uploading an asset (data_assets_tool.create_asset) and uploading or replacing a custom font file (data_fonts_tool.create_font and replace_font_file) use a two-step flow: the tool returns a presigned Amazon S3 URL, and the client is expected to send the file's bytes directly to that URL. If the client's environment or network blocks outbound requests to S3, that second step cannot complete and the upload fails. When that happens, upload the file manually in Webflow (for example, the Designer's asset panel for assets, or site settings for fonts) rather than through the MCP server.
• One workspace per authorization. When you authorize the MCP server, you choose which workspace it can access, and only a single workspace can be selected. To use the MCP server with a different workspace, you will need to reauthenticate. In the case of Claude, OpenAI and others, this means removing the connector/app and reinstalling it.

Agents can now build interactions, filter your CMS faster, and deploy or debug a Webflow Cloud app through MCP.

We're introducing new capabilities for MCP. Agents can now add interactions to a page, query your CMS faster, deploy or debug a Webflow Cloud app, and manage the full branch lifecycle, all without switching tools or waiting on someone else.

This makes it possible to:

• Create and edit interactions, built on IX3 and GSAP, the same way you would on the canvas: scroll, hover, load, and click triggers
• Sort, filter, and page through CMS content, including custom and reference fields, all in a single request
• Deploy, check status, and debug a Webflow Cloud app directly from your MCP client
• Pull main into a branch, merge it back, publish a preview to staging, and check for conflicts before merging. Enterprise plans only.

Check out our developer docs to see how it works.

v2.8.0 introduces webflow apps, the new canonical command namespace for managing Webflow Cloud apps.

It replaces the piecemeal webflow cloud commands with one consistent surface across the whole app lifecycle, designed so a CI job or an AI agent can drive it end-to-end without scraping human-oriented output: structured --json on read commands, --dry-run previews on every write, and predictable exit codes throughout. Reads also retry transient rate limits (429) automatically with bounded backoff, so a busy CI runner doesn't need its own retry loop.

webflow cloud init and webflow cloud deploy keep working unchanged — they now print a one-time deprecation notice pointing at the apps equivalents.

An app is standalone by default — it gets its own subdomain and isn't tied to a Webflow site. Attaching to an existing site (mounted at a path, alongside a Designer-built site) is fully supported too; it's just one additional flag away.

App lifecycle: apps init / apps deploy

Standalone — the default. Owns its own subdomain, no Webflow site involved.

webflow apps init -n my-app -f astro --new -w <workspaceId>
webflow apps deploy -e main

Once webflow.json has an app_id, subsequent apps deploy calls need no flags at all — it's the standalone path that gets simpler over time, since there's no site or mount path to keep in sync.

apps deploy also takes --dry-run and --json, same as every other write in this namespace:

webflow apps deploy -e main --dry-run
webflow apps deploy -e main --json

--dry-run resolves everything from flags, WEBFLOW_APP_ID, and webflow.json — no network calls, no prompts, no changes — and reports which of create / deploy / select the real run would take. --json suppresses the build/upload progress output and emits a single document: {appId, environmentId, deploymentId, deployUrl} on success, an error document on failure, or the dry-run plan when combined with --dry-run.

Attaching to an existing Webflow site instead just adds --site-id and a --mount path at init:

Site-attached — mounted at a path on an existing Webflow site.

webflow apps init -n my-app -f astro -s <siteId> -m /app
webflow apps deploy -e main --site-id <siteId> --mount /app

apps init also supports creating an app directly from an existing GitHub repository, either standalone or attached to a site:

webflow apps init --import https://github.com/<owner>/<repo> --new --dry-run
webflow apps init --import https://github.com/<owner>/<repo> --site-id <siteId> --mount /app --dry-run
webflow apps init --import https://github.com/<owner>/<repo> --new --skip-clone
webflow apps init --import https://github.com/<owner>/<repo> --branch staging --new --idempotency-key $GITHUB_RUN_ID-$REPOSITORY

The Webflow GitHub App must be installed on the repository and connected to your workspace. --dry-run previews the app that would be created; --branch picks which branch to build (defaults to the repository's default branch); --skip-clone creates the app from the remote repository without cloning it into a local directory. --idempotency-key is required for non-interactive runs (CI, --no-input) — reuse a retry-stable key unique to the repository and target so a retry replays the original app instead of creating a second one.

Link an existing app: apps link

webflow apps link <appId> --workspace-id <workspaceId> --dry-run

Points the current directory at an app and environment that already exist by writing the resolved IDs into webflow.json. It only verifies the app — it doesn't create or deploy anything, so it's the fastest way to get a checked-out repo working with apps deploy / apps env-vars / apps logs against an app someone else created. A workspace ID is persisted only when --workspace-id is passed explicitly, since it can't be derived or verified from the app itself. Use --dry-run to preview.

Inspect apps: apps list / apps get / apps domains

webflow apps list --json
webflow apps get <appId> --fields id,name,siteId,sourceUrl --json
webflow apps domains <appId>

list returns every app the token can see — standalone and site-attached alike — and optionally narrows with an exact --site or --name, or a case-insensitive substring --q; combine --site and --name to resolve to at most one app. All three support --fields to project columns and --json for machine-readable output.

Manage apps: apps update / apps delete

webflow apps update <appId> --name "New name" --description "Internal tools dashboard" --dry-run --json
webflow apps update <appId> --github-source https://github.com/<owner>/<repo> --json
webflow apps delete <appId> --dry-run --json
webflow apps delete <appId> --yes --json

Update an app's name, description, and/or GitHub source (at least one of --name / --description / --github-source is required). --github-source attaches a repository to an app that has none, or repoints one that already has a different repo — it doesn't deploy on its own, so follow it with apps deployments trigger. apps delete deletes (archives) an app outright; it refuses to run non-interactively without --yes (a safe --dry-run preview is exempt).

Both commands preview with --dry-run before making any change, and both support --json on every path:

update --json prints the plan (only the keys actually being changed, plus dryRun: true) on a dry run, and the full updated app object on a real run.

delete --json prints one document shape on both the dry run and the real run — { appId, name, action: "archive" | "hard_delete", siteId, siteName, permanent, dryRun, message } — so a caller can parse the same fields either way; message is null until the delete actually happens.

Environments: apps environments list/create/update/delete

webflow apps environments list <appId> --branch main --json
webflow apps environments create <appId> --branch feature/checkout --mount /checkout --dry-run
webflow apps environments update <appId> <envId> --branch main --dry-run
webflow apps environments delete <appId> <envId> --dry-run

list filters by an exact --branch or a substring --q on branch name. create provisions a new environment bound to a branch and served at a mount path — it starts empty; run apps deployments trigger to build it. update changes an environment's branch and/or mount (at least one is required) but doesn't deploy the change itself. delete removes an environment. All three writes support --dry-run, and resolve the app/environment from positional args, WEBFLOW_APP_ID / WEBFLOW_APP_ENVIRONMENT_ID, webflow.json, or an interactive picker.

Deployments: apps deployments list/get/redeploy/trigger

webflow apps deployments list --status failed --json
webflow apps deployments get <deploymentId> --wait --interval 10 --timeout 300 --json
webflow apps deployments trigger --wait --json
webflow apps deployments redeploy <deploymentId> --idempotency-key $GITHUB_RUN_ID --wait --json

list --status filters on an exact status (success, failed, starting, building, deploying, canceled, unstaged). get --wait polls until the deployment reaches a terminal status and exits 0/1 accordingly — built for CI gating; --interval and --timeout tune the poll (floored at 5s, capped at 30min).

trigger builds a GitHub-connected environment's current HEAD on demand; redeploy re-runs a past deployment at the same commit, the rollback path. Both require a GitHub-connected app (not eligible for apps deployed from local files via apps deploy) and now also take --wait (with the same --interval/--timeout): since enqueuing a build only returns a 202 with no deployment ID to poll, --wait identifies the new deployment itself and then blocks on it exactly like deployments get --wait — so a CI job can trigger a build and gate on its outcome in one command. All three writes support --dry-run.

Logs: apps logs build / apps logs runtime

webflow apps logs build <deploymentId> --since <iso> --q <text>
webflow apps logs runtime [envId] --limit 200 --json

Both support --fields, --json, and cursor-based pagination via --cursor.

Environment variables: apps env-vars list/set/delete/import

The headline addition this release: full, non-interactive management of Cloud app environment variables, so secrets no longer require a trip to the dashboard.

webflow apps env-vars list --fields key,isSecret --json
webflow apps env-vars list --q API --json
printf %s "$VALUE" | webflow apps env-vars set API_KEY --secret
webflow apps env-vars delete OLD_KEY --dry-run
webflow apps env-vars import .env --secret --dry-run

--app-id / --environment-id default from webflow.json (cloud.app_id / cloud.environment_id) when present — as shown above — so most invocations inside a project directory need neither flag. Pass them explicitly (--app-id <id> --environment-id <id>) to target a different app, for example from a shared CI runner.

list also takes an exact --key or a case-insensitive substring --q, same filtering pattern as apps list and apps environments list.

set <key> [value] takes the value three ways, safest first: piped stdin (shown above — works in CI with no TTY), an interactive prompt (masked for secrets) if you omit the value entirely, or a positional argument. A positional secret still works but prints a warning, since it lands in your shell history and process list — stdin or the prompt avoid that.

--secret marks a variable encrypted. Secret values are never echoed back — set on a secret confirms only that it was written, and list never returns a secret's value — it comes back masked. Non-secret values are hidden from the default output too, and shown only if you ask for them with --fields value or --json.

import <file> bulk-loads a .env (or any KEY=value) file in one call instead of setting variables one by one. --dry-run parses and previews the resulting key set — secret values shown redacted — without making any API calls or writing anything.

Every write command (set, delete, import) supports --dry-run and --json.

Also in this release

apps init --site-id <id> --no-input now correctly attaches the new app to the existing site and runs the DevLink export, instead of silently falling back to a standalone app without one.

The publicUrl field on an environment (apps environments list/create/update) replaces the old deployUrl field name.

Upgrading

npm install -g @webflow/webflow-cli@latest

Add Webflow components directly to rich text fields, both on canvas and in the CMS panel.

Components like CTA buttons, testimonial cards, and pricing tables can elevate your content, and guide users through their discovery journeys. But until now, these often required third-party solutions or custom code embeds.

Starting today, you can add any Webflow component directly into rich text, on the canvas or in the CMS panel, and configure its properties per item. Update the component once, and every instance across your CMS updates with it.

This will make it much easier to create and maintain functional CMS content that’s optimized for conversions.

How it works:

• Open a rich text field or element and hit / (or the + button) to bring up the insert menu.
• Choose Component, pick the one you want, and it drops in at your cursor.
• The component’s settings open automatically so you can configure that instance's properties right away.

Please note: Components containing Collection Lists can’t be placed in rich text. Additionally, components within rich text can’t be bound to the CMS, and their slots can’t be exposed.

Support for components in the CMS will begin rolling out today, and should be available to all users in the next week.

It can be difficult to maintain design consistency and quality across breakpoints — often requiring repeated context switching. Today, we’ll begin rolling out breakpoint canvas, so you can edit with all breakpoints side-by-side in a unified view.

With this release you can expand your canvas to see your desktop, tablet, mobile, and large breakpoints side-by-side for instant visibility into cascading changes. Alternatively, you can focus your canvas on a single breakpoint for scroll-based interactions, or a more browser-like experience.

This makes responsive design easier while you’re building, and it makes your AI agent’s changes much easier to review across devices, so you can maintain your design consistency and quality without the constant context switching.

Breakpoint canvas is rolling out now and will be available to all Webflow users in Design, Build, and Edit modes in the next week.

Please note: breakpoint canvas will not be available in Preview or Comment mode.

Today in the Webflow Conference keynote, we unveiled Source by Webflow: a new platform for marketing teams and their agents to launch, optimize, and scale digital experiences, together.

‍Source connects with your codebase and martech stack, bringing agentic and visual development into a shared operating environment, with every marketer, designer, and developer getting a workspace tailored to their job and the outcomes they own.

AI has made building easier. Anyone can ship a site through prompting, but building is only one part of the job. The hard part is what comes after: scaling what works, knowing what to change, and driving impact with every iteration.

That's especially true on the web, where AI has fundamentally changed how buyers discover, evaluate, and choose brands, raising the stakes from first impression to final conversion. Teams need to work synchronously with agents to ship campaigns, optimize for AI discovery, test variants for CRO, and localize across markets — continuously, not just at launch. But existing solutions haven't caught up to that reality.

What Source unlocks

That’s why we built Source: one system designed from the ground up for marketing teams and agents to drive growth on the web together. Here’s what it unlocks:

Agentic scale with visual control, on one surface.

Source makes code the foundation for everything that ships on your site. With direct access to that code, Source’s agents can take on larger, more complex changes without the constraints of an abstraction layer. And when the work calls for a human hand or precise finishing touch, Source brings the best of Webflow’s visual canvas, with every edit writing to that same underlying code. The result: AI speed while maintaining craft and control.

Views: a new way to tailor workspaces to your team.

Every marketer, designer, and developer gets a unique workspace powered by Views: a new primitive that lets teams shape their software to the exact jobs and outcomes they own. Views are dedicated surfaces for visual site building, campaigns, content, optimization, and can be custom-built for any workflow your team needs. Each workspace is governed with brand systems, role-based access, approval paths, and audit trails from day one, so your team of practitioners and agents can move fast within the right guardrails.

A shared operating layer across your existing stack.

Source is composable by default, bringing your codebase, CMS, hosting, and marketing tools (including sites you’ve already built in Webflow) into one environment where teams and agents work together. Whether you want to keep the infrastructure you’ve invested in or leverage Webflow’s native solutions, Source provides the flexible workspaces, governance, and agentic layer your team needs to launch, optimize, and scale the web.

Join us as we shape the future of web marketing

Source is currently in a limited research preview, and we’ll be enrolling select agency partners and customers in a phased approach over the coming months.

Fill out the form on webflow.com/source to stay in the loop on updates, or if you want a hand in shaping what's next, check the box and apply to join the research preview. If you’re approved, we’ll reach out with next steps.

To learn more details about what we're building with Source, how it comes to life across your team, and what our agency partners co-developing Source with us are saying, read the full announcement blog.

We're introducing visual editing for AI code components, bringing the same direct, on-canvas control to AI-generated elements that Webflow has always given native ones.

This makes it possible to:

• Select any element inside a code component and adjust it in the Style Panel, the same way you'd style any other Webflow element
• Add an element as context in a prompt, so the AI Assistant scopes changes to that element specifically
• Manually edit text on the canvas

AI code components now work like everything else in Webflow. Generate a component, then refine it directly, no prompt required for the small stuff.

Check out our help center article to see how it works

We're introducing Agent Instructions Generation. Instead of starting from a blank editor, agents can generate a first draft of Brand Guidelines, Design System, Asset Guidelines, and CMS Guidelines straight from your site.

This makes it possible to:

• Generate Brand Guidelines that capture your brand's voice, tone, and personality
• Generate a Design System guide that documents your components, variables, and how they're meant to be used
• Generate Asset Guidelines for how images and media should look and behave across your site
• Generate CMS Guidelines that document your collection structure and field-level rules

Every draft comes from your actual site, not a generic template. Everything it creates is yours to edit, and nothing is locked.

Check out our help docs to see how it works.

Designers can now control which components are allowed in component slots, helping Marketers build confidently while keeping layouts intact.

Nothing hurts more than handing off a carefully designed component system only to have a layout break because the wrong component was placed in a slot. Designers end up doing cleanup work to make everything fit back together, while Marketers have to wait for fixes before they can keep building.

Until now, there wasn’t a way to define which components were intended for a particular slot. That ambiguity could lead to mistakes, broken layouts, and unnecessary back-and-forth.

Starting today, anyone with the Designer or Site manager role (or equivalent custom role) can control which components are allowed in a given component slot.

Here’s what you can expect:

• Designers set the guardrails, Marketers build with confidence. Designers can define exactly which components belong in each slot, so Marketers don’t have to guess what works where.
• Mistakes get caught immediately. If a Marketer tries to add a component that isn’t allowed, they’ll see a clear message showing which components are permitted in that slot.
• Add guardrails only where they’re needed. Slots continue to allow all components by default, so Designers can introduce restrictions selectively without changing how the rest of their component system works.

The Branch API (beta) is now documented for Enterprise sites with page branching enabled.

Branches

• Overview — lifecycle, async tasks, conflicts, and entitlement requirements
• List Branches — paginated branch list with computed status and nextActions
• Create Branch — enqueue branch creation from a page
• Get Branch — single branch with status
• Delete Branch — enqueue branch deletion (202 + task poll)
• Get Branch Conflicts — unresolved style and component conflicts
• Update Branch — pull main changes into a branch
• Merge Branch — merge a branch into main
• Publish Branch — publish a branch preview to its staging domain
• Get Branch Task Status — poll async branch tasks

Webhooks

branch_created, branch_merged, and branch_deleted event schemas are documented under All Events. Successful merges fire branch_merged only — not branch_deleted.

One Light, Dark, or System theme for the Webflow UI — applied consistently as you move around the product.

One appearance preference for Webflow — System, Light, or Dark — now follows you across Dashboard, Sites and Optimize sites. This includes Light mode in Sites.

Choose your theme

Pick System, Light, or Dark. If you choose Dark, you can also pick Darker, Default, or Brighter. System follows your operating system's light or dark appearance.

One setting across product surfaces

Your preference saves to your account. Move between product areas without resetting theme on each surface.

This controls the Webflow interface — not your published site.