Code Export and Portability

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 exporting a Webflow site as it was on 2026-10-28, the date on which its facts were checked against the official documentation. Webflow is a hosted service without version numbers, so the page is dated rather than versioned; Webflow updates announces changes and Product Changes and Deprecations tracks the ones that matter for this sub-section. Plans are named by tier only and this page quotes no prices (see Plans, Workspaces, Seats and Roles).

Webflow publishes sites to its own hosting, but a site is not trapped there: the Designer can produce a ZIP file with the static HTML, CSS, JavaScript and media of the site, and the CMS and Ecommerce data can be downloaded as CSV. Both exports are real, and both are partial. The export is a snapshot of the front end, not a copy of the platform: every feature that needs a Webflow server (CMS lists, forms, Ecommerce, site search, password protection, localization) does not come with it. Understanding exactly where that line falls is the foundation of any decision to leave Webflow, to hand a site to a client who hosts it themselves, or to keep an archive.

The running example is the Fernbrook Gardens site, a fictitious botanical garden with a Home page, a Visit page with a contact form, a Plants collection with a template page, and a small shop. The question this page answers is: what would Fernbrook own, and what would it still have to build, if it moved off Webflow hosting tomorrow?

Who can export code

Exporting the code of a site is a paid-Workspace feature. The Help Center article on exporting site code states that exporting requires a paid Workspace plan, and that the option is not available for sites in a Developer workspace. In practice:

  • A site in a Starter Workspace (the free tier) cannot export its code.

  • A site in a Developer workspace cannot export its code either. The Developer workspace is the free workspace used throughout this sub-section for API and app development; it exists to build and test, not to hand off code.

  • A site in a paid Workspace plan can export code, subject to the plan the Workspace has on the day of the export.

  • The export is a Workspace feature, not a site-plan feature. Hosting the site on a Basic, CMS or Business site plan is not what unlocks it, and a site plan on its own does not unlock it on a Starter Workspace.

Where the site lives Code export Note

Starter Workspace

No

Upgrade the Workspace plan to enable it

Developer workspace

No

Disabled by design; use the Data API or CSV for content

Paid Workspace plan

Yes

Needs permission to export (see the roles page)

Source: Webflow Help Center: How do I export my Webflow site code?

Correcting older books

An older book on Webflow, written in 2021, states the rule twice and the two statements disagree: once it ties code export to the account-level Lite plan, and once to a paid site plan. Neither matches today’s documentation. The Lite, Pro and Team account plans no longer exist, and the rule is not decided by the site plan at all; it is decided by the Workspace plan, with Starter Workspaces and Developer workspaces excluded. When a tutorial disagrees with the Help Center, follow the Help Center, and see Where Older Books and Tutorials Are Outdated for the full list of outdated statements.

How to export

The export is started from the Designer and downloaded as a ZIP file.

  1. Open the site in the Designer.

  2. Open the Export code option from the Designer’s main menu (the Webflow logo menu).

  3. Choose the options offered by the dialog.

  4. Select Prepare ZIP and wait; large sites take a while.

  5. Download the ZIP and unpack it into an empty folder.

Menu labels move between Designer releases, so look for the export entry in the Designer’s main menu rather than relying on a fixed position. The ZIP reflects the site at the moment the export was prepared; compare it with the published site before relying on it as an archive.

Source: Webflow Help Center: How do I export my Webflow site code?

The exported file structure

An export is a plain static website. A typical export of the Fernbrook Gardens site looks like this.

fernbrook-gardens.zip
├── index.html                  Home page
├── visit.html                  Visit page (contains the contact form)
├── 404.html
├── plants/
│   └── plant-template.html     CMS template page, without items
├── css/
│   ├── normalize.css           browser normalisation
│   ├── webflow.css             Webflow framework styles (w- classes)
│   └── fernbrook-gardens.webflow.css   the site's own classes
├── js/
│   └── webflow.js              widgets, Interactions, form handling
├── images/                     uploaded images and generated responsive variants
├── fonts/                      uploaded custom fonts, if any
└── documents/                  uploaded PDFs and other files

Three points matter when reading the tree.

  • The names are not stable. The layout shown is the shape of a typical export; file names and the number of stylesheets depend on the export options and the Webflow release. The published site on Webflow hosting can use a different file split (a shared stylesheet plus a page stylesheet) from the one produced by an export, as described in HTML and CSS in Webflow.

  • Pages are plain HTML files. Each page is one HTML document with its markup, its class names and its data-wf-site and data-wf-page attributes. Links between pages are relative file links.

  • CMS template pages are there, items are not. A collection template page is exported as a single HTML file whose collection lists and dynamic fields have no data behind them. See the next section.

The head of an exported page keeps the identifiers that Webflow’s script uses.

<!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</title>
  <meta content="width=device-width, initial-scale=1" name="viewport">
  <link href="css/normalize.css" rel="stylesheet" type="text/css">
  <link href="css/webflow.css" rel="stylesheet" type="text/css">
  <link href="css/fernbrook-gardens.webflow.css" rel="stylesheet" type="text/css">
</head>
<body>
  <!-- the page body, with Webflow classes -->
  <script src="js/webflow.js" type="text/javascript"></script>
</body>
</html>

The identifiers above are placeholders. The real values are generated per site and page and should stay in the file.

Source: Webflow Help Center: How do I export my Webflow site code?

What keeps working

Because the export is what the browser executes on the published site, everything that is pure front end keeps working once the files are served from any static host.

  • HTML and CSS. Layout, typography, classes, combo classes, responsive breakpoints, hover and focus states, variables and the media queries behind them are ordinary CSS and render the same way.

  • Images and fonts. Uploaded assets are in the ZIP and are referenced by relative paths. Fonts loaded from an external provider still need that provider to be reachable.

  • Interactions and animations. Webflow’s Interactions are driven by data attributes in the markup and by webflow.js, which is in the ZIP. They run without a Webflow server.

  • Built-in widgets. The Navbar, Tabs, Slider, Lightbox and Dropdown elements are initialised by webflow.js using the data-wf-site and data-wf-page attributes. Remove the script or the attributes and the mobile menu stops opening and the slider stops sliding.

  • Custom code. Code in the head and body of a page, embeds and custom attributes are plain HTML and travel with the export, provided they do not call back to Webflow.

Keeps working Why

Layout and styles

Plain CSS files

Interactions

Data attributes plus webflow.js

Navbar, Slider, Tabs, Lightbox, Dropdown

Initialised by webflow.js

Static copy, images, fonts, documents

Files in the ZIP

Custom code and embeds

Plain HTML and JavaScript

The practical rule: do not edit or reorder the Webflow scripts and stylesheets, and keep the data-wf-* attributes. A site that is edited by hand after export drifts from the Designer, and a later export will overwrite those changes.

Source: Webflow Help Center: How do I export my Webflow site code?

What is lost

Everything that needs Webflow’s servers is missing or inert in an export. The Help Center article lists these limitations; this table adds what to do about each one for Fernbrook Gardens.

Feature What happens in the export What to do at the new host

CMS

Collection lists render empty; template pages have no items

Export the data as CSV or through the Data API and rebuild the pages with a generator or a database

Ecommerce

Products, cart, checkout and orders do not work

Move the shop to another platform; export products and customers as CSV

Forms

The form markup is present but submissions are no longer processed by Webflow

Point the form action at your own endpoint or a form service

reCAPTCHA

Does not work in an export

Add the CAPTCHA provider’s own script and server-side check

Site search

No search results

Use a client-side search library or a hosted search service

Password protection

No page or site protection

Protect at the web server or CDN

Localization

Locales and localized content are not produced

Build per-locale pages by hand or with a generator

Code components

Do not render

Export the components with DevLink instead (see below)

Two consequences deserve emphasis.

  • A site that is mostly marketing pages with a contact form exports well: the front end is complete and only the form needs a replacement.

  • A site whose value is its CMS or shop does not export as a working site. It exports as a design, plus data in CSV. This is the single most important fact when deciding whether Webflow is a fit for a project that may later need to move.

Source: Webflow Help Center: How do I export my Webflow site code?

Exporting CMS and Ecommerce data as CSV

Content is exported separately from code. Each CMS collection can be exported to a CSV file from the CMS panel or from the collection’s settings, and Ecommerce data (products, orders and customers) can be exported as CSV from the Ecommerce area of the Designer or the dashboard. The CSV contains the item fields as columns; reference fields hold the slugs or names of the referenced items; images and files are exported as URLs, not as the files themselves. The export of the files themselves is not part of the CSV: download the assets from the Assets panel, or fetch the URLs before the site is closed.

A shortened export of the Fernbrook Plants collection looks like this.

Name,Slug,Collection ID,Item ID,Created On,Updated On,Published On,Latin name,Light,Bloom season,Photo
Fern Cluster,fern-cluster,COLLECTION_ID_PLACEHOLDER,ITEM_ID_PLACEHOLDER_1,2026-03-04,2026-09-12,2026-09-12,Polystichum setiferum,Shade,Spring,https://cdn.example.com/fern-cluster.jpg
Autumn Aster,autumn-aster,COLLECTION_ID_PLACEHOLDER,ITEM_ID_PLACEHOLDER_2,2026-03-04,2026-10-01,2026-10-01,Symphyotrichum novi-belgii,Sun,Autumn,https://cdn.example.com/autumn-aster.jpg

The column set mirrors the collection’s fields, so the header of a real file depends on the collection. The values above, including the image host, are illustrative. The same CSV can be imported back into a collection with the matching column names, which is the subject of CSV Import and Export. A CSV is the simplest portable format: any spreadsheet, database loader or static-site generator can read it.

Source: Webflow: Export content as a CSV

For larger or repeated exports, the Data API returns the same items as JSON and is the right tool for scripted migration; the Content Delivery API is the read-only, cache-friendly variant for serving content from your own front end. Both are covered in Content Delivery API and Headless and need a site that is still published on Webflow, which makes them an alternative to export rather than a result of it.

Hosting the exported code elsewhere

An exported site is a folder of static files, so any static host works: object storage with a CDN, a static-hosting service, or your own web server. The following nginx configuration serves the Fernbrook export from /var/www/fernbrook, with clean URLs, long caching for assets and the 404 page.

server {
    listen 80;
    server_name fernbrook.example;
    root /var/www/fernbrook;
    index index.html;

    # /visit serves visit.html
    location / {
        try_files $uri $uri.html $uri/ =404;
    }

    # Fingerprint-free assets: cache for a day, revalidate afterwards
    location ~* \.(css|js|png|jpg|jpeg|webp|avif|svg|woff2)$ {
        expires 1d;
        add_header Cache-Control "public, must-revalidate";
    }

    error_page 404 /404.html;
}

Source: nginx: ngx_http_core_module

Redirects from the old URLs, the canonical domain and the sitemap are not produced by the export; recreate the 301 redirects in the web server configuration. The method, and how to compare old and new URLs, is in Redirects and Site Migration. If you want to keep Webflow as the editor and the host while only fronting it with your own infrastructure, a reverse proxy is the alternative to an export; see Domains, Hosting and Publishing Options.

Replacing the contact form

The Visit page’s form posts to Webflow when it is hosted there. After an export, the same markup has nowhere to post. Replace the form’s action with an endpoint you control, and keep the name attributes so the fields stay the same.

<form action="https://forms.fernbrook.example/api/contact" method="post">
  <label for="visitor-name">Name</label>
  <input id="visitor-name" name="name" type="text" required>

  <label for="visitor-email">Email</label>
  <input id="visitor-email" name="email" type="email" required>

  <label for="visitor-message">Message</label>
  <textarea id="visitor-message" name="message" required></textarea>

  <!-- honeypot field: hidden from people, filled by bots -->
  <input name="website" type="text" tabindex="-1" autocomplete="off" hidden>

  <button type="submit">Send message</button>
</form>

The endpoint URL is a placeholder: it may be your own small server, a serverless function or a hosted form service. It must validate input, apply its own spam protection (the honeypot above is the minimum) and return a redirect to a thank-you page. Webflow’s own spam filtering and reCAPTCHA integration are not available outside its hosting. For the behaviour being replaced, see Forms.

Source: MDN: Sending form data

DevLink export: the component-level alternative

Exporting a whole site is one way to leave Webflow’s hosting. The other is to keep using Webflow as the visual design tool for individual components and export those into a React codebase. DevLink exports Webflow components, with their styles and variants, as React components that a Next.js or other React application imports, so the application owns routing, data and hosting while designers keep editing the components visually. Interactions on exported components have their own guidelines in the DevLink component export interaction guidelines.

Code export (ZIP) DevLink export

Unit

The whole site

Individual components

Result

Static HTML, CSS, JavaScript

React components and CSS

Plans

Paid Workspace plan

See the DevLink page for the current rule

Data and routing

Not included

You build them in your application

Typical use

Archive, hand-off, static hosting

Design system inside a coded application

Continues after export

No, one-off snapshot

Yes, components are synced on demand

DevLink is covered in depth in DevLink Export. The decision between exporting a site, using DevLink and going headless with the APIs is part of Comparison and Decision Guide.

Source: Webflow Developer Docs: DevLink interactions guidelines

Lock-in considerations

Lock-in is not all-or-nothing. Some assets are portable by design and some cannot leave.

Asset Portable Notes

HTML, CSS, JavaScript of the front end

Yes

Through code export; paid Workspace only

Uploaded images, fonts, documents

Yes

In the ZIP or through the Assets panel

CMS items

Yes

CSV, Data API; images are URLs

Ecommerce products, orders, customers

Yes

CSV; the shop logic is not

Custom code and embeds

Yes

Plain code in the markup

Components

Partly

DevLink export to React; the Designer component model itself stays in Webflow

Interactions

Partly

Run in the export through webflow.js; cannot be edited outside the Designer

Forms, submissions

Partly

Submissions can be downloaded as CSV; processing is Webflow’s

Localization, site search, password protection

No

Rebuild at the new host

Designer project, class system, variables

No

There is no import into the Designer from exported code

The last row is the important asymmetry: exported code cannot be imported back into the Designer as an editable project. After a handoff the HTML belongs to whoever maintains it by hand, and the visual workflow is gone. Keep this in mind when choosing between a one-off export and keeping the site live on Webflow.

Source: Webflow Help Center: How do I export my Webflow site code?

Migration and portability checklist

Use this checklist before deciding to leave Webflow hosting, and again before the cut-over.

  1. Confirm the Workspace plan allows code export; if the site is in a Developer or Starter Workspace, plan to move it to a paid Workspace first.

  2. Make a backup in the Designer so there is a restore point, and note the live site’s published date (see Backups and Recovery).

  3. Export the code and unpack it into a clean folder under version control.

  4. Export every CMS collection and the Ecommerce data as CSV, and download the assets referenced by URL.

  5. List the lost features from this page, and for each choose a replacement: form endpoint, search, protection, localization, shop.

  6. Replace form actions and any script that talks to Webflow; remove reCAPTCHA markup that cannot work.

  7. Serve the folder from a staging host and compare it page by page with the published Webflow site, including mobile menu, slider, tabs and Interactions.

  8. Recreate the 301 redirects, the sitemap and robots rules, and check canonical URLs.

  9. Lower the DNS time to live ahead of the cut-over, switch the domain, and keep the Webflow site live for a rollback window.

  10. Cancel the Webflow site plan only after traffic, forms and search results look right at the new host.

Pitfalls

  • Treating the export as a CMS migration. It is not; the items stay behind, in CSV, and the pages become empty templates.

  • Forgetting that the forms stop working. The page looks fine, and submissions disappear silently until the action is replaced.

  • Editing the exported files and expecting a round trip. There is no way to import them into the Designer.

  • Deleting the data-wf-* attributes or webflow.js. The Navbar, Slider, Tabs and Interactions break.

  • Assuming the plan rule from an older tutorial. Code export depends on the Workspace plan, not on a site plan.

  • Exporting only once. The export is a snapshot; repeat it, and the CSV exports, whenever the live site changes if the export is meant to be an archive.

References