Almost always because of fear rather than a technical need. Someone in the room asks what happens if Webflow raises prices, gets acquired, or shuts down, and exporting the code sounds like the responsible answer. It feels like an insurance policy. In practice it is a much narrower tool than that.
We get asked this on nearly every enterprise-adjacent project, usually by a technical stakeholder who has been burned by a platform before. The instinct is completely reasonable. The conclusion people draw from it is usually wrong.
Our position, stated plainly: code export is the right call for a small number of specific situations, and the wrong call as a general safety net. The rest of this article explains where that line sits, using what Webflow itself documents about what you actually get.
Code export gives you a downloadable package of the static front end of your site. That means the HTML for your static pages, the compiled CSS, the JavaScript that powers your interactions, and your uploaded image assets. You can host that package anywhere that serves static files.
What you get is genuinely clean. This is one of the real arguments for Webflow over builders that generate tangled markup, because the exported HTML is readable and the CSS is compiled rather than scattered. Anyone who knows front-end code can pick it up.
The important word is static. The export is a snapshot of what your site looked like at the moment you exported it. It is not a live connection to anything, and it does not update when you change something in the Designer.
That distinction is the whole subject. Everything that makes a modern Webflow site useful beyond its markup lives on Webflow's servers, and the export does not bring that with it.
More than most people expect. Webflow's own help documentation is direct about it: CMS, User Accounts, and Ecommerce content are not included in exported code. Those are databases, and they stay behind.
The consequence is visible immediately. Webflow documents that Collection lists will show the empty state, and Collection pages will not show any content bound to Collection fields. If your site has a blog, a case study library, or a product catalogue, those sections come out hollow.
Forms and site search stop working too. Webflow states that site search and forms, including file upload and reCAPTCHA, will not work on exported sites in order to comply with GDPR. A contact form is usually the single most commercially important element on a business site, and it is dead on arrival after an export.
Password protection is the one that should worry security-minded readers. Webflow's documentation says password protected pages will no longer be protected after code export. A page you thought was private becomes a plain file on whatever server you uploaded it to.
Code components and their functionality, along with localized pages, elements, and content, are also excluded. Webflow does let you export CMS Collections, Ecommerce Collections, and User Accounts separately in CSV format, so your data is recoverable, but recovering data is not the same as having a working site.
Code export sits on a paid Workspace plan, not on a site plan. This is the detail that catches people out, because paying for hosting on a site does not unlock the ability to take the code off it. They are two separate products in Webflow's billing.
Be careful with older advice here. Webflow has restructured its plans, and guides written even a year ago reference tier names that have changed. Before you budget for an export, check the current pricing page rather than trusting a blog post, including this one.
It is worth doing that arithmetic honestly. If you are paying for a Workspace plan purely so that you can export a copy of the site into a drawer, you are paying a recurring fee for a snapshot you will probably never use.
Partially, and less than it feels. You get your design and your markup, which is the part that took the most effort to create. You do not get a functioning website, because the parts that make it function are exactly the parts that do not come along.
Think about what a real migration off Webflow would involve. You would need to rebuild the CMS in something else, rewire every Collection list to the new data source, rebuild your forms and their handling, replace search, and reimplement authentication if you had it. The exported HTML shortens the design work and none of the rest.
There is a more honest form of the same insurance. Keep your content exported as CSV on a schedule, keep your images somewhere you control, and make sure your domain is registered in your own account rather than an agency's. Those three habits protect you more than a stale code export ever will.
We would also gently point out that the code export goes stale the day after you take it. Unless someone re-exports on a schedule, the emergency copy in your drawer is a version of the site from months ago, missing every change since.
There are three we consider legitimate. The first is a genuinely static site with no CMS, no forms, and no logins, where the export is a complete site rather than a fragment. Marketing microsites and one-page campaigns fit this well.
The second is a handoff into an existing engineering stack. If a client's team is going to take the markup and rebuild it inside their own framework, then Webflow was the design tool and the export is the deliverable. That is a sensible way to use it, and it is honest about what Webflow contributed.
The third is a hard compliance requirement. Some organisations must host on infrastructure they control, and that requirement is not negotiable regardless of how good the platform is. In those cases the losses documented above are simply the cost of doing business.
Notice what is not on that list. "In case something goes wrong" is not a reason, because the export does not solve the scenario people imagine when they say it. If you want a deeper comparison of the two approaches, we wrote about the tradeoffs in Webflow versus custom code.
If your concern is control rather than escape, Webflow has moved a long way toward meeting you. Webflow Cloud offers app hosting, and Webflow's pricing page now lists it on every site plan including the free Starter tier, which was not true of earlier hosting models.
DevLink is the other piece worth knowing about. It lets teams bring Webflow-built components into a React codebase, which addresses the real underlying want in most of these conversations. People rarely want to leave Webflow. They want their engineering team to be able to use what the design team built.
There is also a Figma to Webflow path in the other direction, which matters if your design system lives in Figma. Between these, the modern answer to "we need our developers involved" is usually integration rather than export. We covered the hosting side of this in our explainer on what Webflow Cloud is and whether you should use it.
If the worry is specifically about losing access rather than losing code, the fix is ownership and process. Making sure the client holds the Webflow account, the domain, and the billing solves more real-world problems than any export does, which is why we treat it as part of every handover.
It costs you the editing experience, which is usually the reason the client chose Webflow. Once the site is exported and hosted elsewhere, nobody can update it through the Designer any more. Every text change becomes a developer task and a redeploy.
It also costs you the hosting Webflow was handling. You now own the CDN configuration, the SSL certificates, the redirects, the caching rules, and the uptime. Platforms like Netlify, Vercel, and Cloudflare Pages make that manageable, but manageable is not the same as free of effort.
The subtler cost is drift. Teams that export usually keep editing in Webflow for a while and re-export periodically, and eventually somebody makes a change directly in the exported code. From that moment the two versions diverge, and the next export overwrites work.
We have seen that pattern often enough to treat it as the default outcome rather than a risk. If you export, decide immediately and permanently which copy is the source of truth, and make sure everyone knows.
Ask one question: after the export, does the site still do its job? If your site is brochure pages with no CMS, no forms, and no logins, the answer is yes, and exporting is low risk. If any of those three are present, the answer is no, and you are choosing to break something.
Then ask who maintains it afterwards. If the answer is a marketing person who is comfortable in the Designer and nowhere else, exporting removes their ability to do their job. That is a bigger operational cost than most technical stakeholders account for.
Finally, ask what problem you are actually solving. Write it down in one sentence. Most of the time the sentence is about ownership, access, or continuity, and each of those has a cleaner solution than exporting. Our guide on handing off a Webflow site to a client covers how we set that up.
If you are considering an export, do the test before you commit. Export a copy, host it somewhere temporary, and click through it. Try the contact form. Look at the blog. Seeing the empty Collection lists yourself is more persuasive than any documentation, and it takes an afternoon.
If the site survives that test, exporting is a reasonable choice and you should go ahead. If it does not, redirect the energy into ownership and backups instead, because that is what the underlying worry was really about.
Either way, set up regular CSV exports of your Collections now. That is the genuinely useful safety net, it costs nothing, and it works whether you ever export the code or not.
If you are weighing this up for a real project and want a second opinion, we are happy to talk it through. Reach out at phoenix.studio and tell us what you are worried about, and we will tell you honestly whether exporting solves it.
Tell us where you want to go. We'll tell you how we'd get you there.