Framer does not provide a full native export that turns a live Framer site into clean, self-hostable HTML, CSS, JavaScript, and source code. You can export some project assets from Framer, convert the published front end of a site you own to a static HTML snapshot, or rebuild the design in another stack. Those are different jobs.
If you searched for "Framer to HTML," "Framer export code," or "Framer to code," start with the honest answer: a static copy can preserve the public front end of many Framer marketing sites, portfolios, and landing pages, but it will not move Framer CMS editing, forms, ecommerce, memberships, private data, or the original visual editor project. A rebuild is better when you need maintainable source code. Staying on Framer is reasonable when the visual workflow is still the main value.
Leaving Framer is therefore not one technical action. It is a small migration: preserve the public pages, identify the services that only Framer provides, replace the ones you need, and move the domain after the new site has been tested. The safest approach keeps the existing site live until the replacement has proven itself. You do not need to cancel first, and you should not start by changing DNS.
Framer to HTML in practice
The practical Framer to HTML path starts with the published URL, not the private project file:
- paste the live Framer URL into a public-site exporter;
- let the exporter crawl reachable public pages, CSS, JavaScript, fonts, images, and files;
- open the copied site and click through the pages you need;
- if the copy preserves those pages, keep the static ZIP;
- deploy the ZIP to a static host, test the routes, and only then move DNS.
This is not a replacement for the full leave-Framer plan below. It is the early proof step: before you choose hosting, cancel a plan, or rebuild templates, confirm whether a static HTML copy of the public site is good enough for your goal.
Export Your Site is one way to create that public-site snapshot. The ZIP holds HTML, CSS, JavaScript, images, fonts, and other browser-visible assets. It does not recover a native Framer project, structured CMS database, or clean application source code.
What "Framer to HTML" actually means
People use "Framer to HTML," "Framer export," and "Framer export code" for different outputs. Confusing them is how migrations go wrong.
Static public-site snapshot
This is the normal meaning in this guide. A crawler visits the published Framer URL, saves the HTML, CSS, JavaScript, images, fonts, and public files that browsers receive, and rewrites references so the copied pages can run from a static host. The output is a hostable snapshot of the public site.
It is practical for archives, temporary self-hosting, and mostly static marketing sites. It is not the Framer source project, and it will not keep CMS, forms, ecommerce, memberships, or private app behavior alive on its own. A hosted snapshot follows that model: paste the public URL, click through the copied site, then keep the static ZIP if the copy is useful.
Official asset export
Framer can help you obtain design and media assets from the project, depending on your access and current product features. That is useful for migration planning, but it is not a full website export. An asset export does not create a portable Framer project, reproduce hosted CMS behavior, or package the live website as a self-hosted app.
Native full code export
Native full code export would mean Framer gives you a clean, self-hostable source project with routes, components, styling, data models, and a build process. Framer does not provide that for a live site. Searches for "Framer to code" often mean this outcome, but browser output is not the same as maintainable source.
Rebuild in maintainable code
Some searches for "Framer export code" really mean "give me a clean React, Astro, or Next.js codebase I can maintain in Git." A static copy is not that. It preserves browser output, including generated class names and bundled scripts. The files are still yours, and an AI assistant can help you change them. If you want a framework codebase, use the export as a reference while rebuilding. The companion guide to Framer alternatives for code ownership can help choose that destination.
Be careful with plugins or services that imply they can reconstruct a clean Framer source project or production-ready React app from the published site. Browser output is not the same thing as the private editor model that produced it.
What a static Framer copy can preserve
For a typical Framer marketing site, expect the browser-facing parts:
- published HTML pages;
- Framer-delivered CSS and JavaScript;
- images, icons, fonts, video posters, and downloadable public files;
- links between captured routes;
- public embeds and scripts that still point at reachable third-party services;
- rendered CMS item pages that normal visitors can open.
The result preserves delivery output, not the authoring system. Generated markup, bundled scripts, responsive image references, and Framer-specific runtime assumptions may remain exactly as delivered. That can be enough for an archive, a temporary self-hosted mirror, or a brochure site that rarely changes.
The important question is not whether a ZIP can be produced. The important question is whether your actual public pages, layouts, CMS entries, interactions, fonts, and assets survived well enough for the migration goal.
What a static Framer copy cannot preserve independently
CMS editing
A static crawl can freeze rendered Framer CMS item pages when they are published, public, reachable, and captured. It does not export the Framer CMS database as structured collections, fields, references, drafts, scheduled changes, Editor permissions, or the workflow that generates future entries.
That distinction matters for "framer export cms" searches. A copied blog post, case study, job listing, or article page is a snapshot of what visitors saw. It is not a content model you can keep editing inside Framer, import automatically into a new CMS, or query through a private Framer API after cancellation.
Forms
The visible fields may remain while the submission workflow still depends on Framer or another hosted endpoint. Replace each form with a form service, serverless function, or application endpoint, then test validation, spam handling, success states, error states, and notification delivery.
Search, memberships, and ecommerce
These are applications, not page decorations. A static ZIP can preserve a public product or landing page, but it cannot preserve inventory, checkout, customer accounts, memberships, gated content, hosted search indexes, or private records.
Editor and project workflow
A public copy cannot recover the private Framer project, canvas, unpublished pages, drafts, comments, permissions, billing settings, or design system as editable source. If those are the assets you need, pursue account access, Framer's current official options, or a deliberate rebuild rather than treating a public copy as a project backup.
Framer CMS backup and leave-with-content options
CMS content deserves a separate decision because "Framer CMS export" can mean source data, public pages, or the future editorial workflow. Do not use one artifact as proof that you have the others.
| CMS exit path | Best for | What you get | What it leaves behind | | --- | --- | --- | --- | | Framer's current official export, API, or migration options where available | Editors or developers who need collection records for another system | Source content in whatever structured format Framer currently supports for your plan and access | A ready-to-host static website, future editor workflow in the new system, and any fields or private states not exposed by the current Framer path | | Manual inventory plus migration into a new CMS | Small collections, messy content, or teams changing their publishing model | A clean map of collections, fields, slugs, rich text, images, authors, categories, and redirects | Automatic preservation of Framer's Editor, drafts, permissions, and generated templates | | Static crawl of published CMS pages | Freezing public articles, case studies, docs, or landing pages as visitors see them | HTML, CSS, JavaScript, images, fonts, and public assets for reachable published item pages | Structured collections as data, drafts, future publishing, field schema ownership, and API-ready records |
1. Inventory collections before you cancel
List every collection, template, and public route that depends on CMS content. Capture representative items for each layout: a normal post, a long rich-text entry, an item with many images, a category page, a paginated list, and any filtered views visitors use.
Record the fields you need later, including slugs, titles, dates, authors, categories, rich text, images, file attachments, SEO titles, descriptions, canonical URLs, and redirects. This inventory tells you whether a static ZIP is enough or whether the content needs to stay structured.
2. Export or migrate source content separately where Framer supports it
If you need editable CMS content after leaving Framer, start with Framer's current documentation for CMS export, APIs, imports, and migration support. Product screens, plan rules, and API coverage change, so use Framer's docs as the source of truth instead of relying on an old click path from a blog post.
This path is best when posts should become Markdown files, collection items should move into WordPress, Ghost, Sanity, Contentful, Payload, a database, or a custom API, or editors need to keep adding entries. Save the source data before cancellation, then inspect representative records for missing images, rich text formatting, references, dates, authors, categories, and slugs.
3. Use a static crawl as a bridge for published pages
A static crawl is useful when the urgent goal is to keep public CMS-backed pages online while a better content workflow is planned. If a Framer blog article, case study, or docs page is public and reachable, the crawler can often preserve the rendered page as static HTML.
A public-site copy stays in that static-crawl lane. The ZIP contains published pages and browser-visible assets only. It is not a Framer CMS editing workflow, structured collection export, draft archive, private CMS API dump, or replacement for a new CMS. If you need CMS data, plan the official export, API, Markdown, or database migration separately.
CMS decision matrix
| Your goal | Static ZIP enough? | Better primary path | | --- | --- | --- | | Archive a mostly static Framer site with a few public CMS-backed pages | Usually, if the copy captures every important route | Static crawl plus manual QA | | Freeze published blog posts, docs, or case studies exactly as visitors saw them | Often, if item pages and listings are public and reachable | Static crawl, with source-data export as a backup if you own the content | | Move posts into a new CMS for ongoing editing | No | Framer's supported export/API paths, manual cleanup, or Markdown/database migration | | Preserve drafts, collection fields, references, Editor permissions, or scheduled publishing | No | Framer account access plus official export/API planning where available | | Rebuild the site in Next.js, Astro, WordPress, Ghost, or another platform | Static ZIP can be a visual reference | Source content migration plus a deliberate template rebuild |
The practical sequence is simple: inspect the published front-end copy first so you know what a static Framer export can preserve. If the copy covers the routes you need, the ZIP can be the archive or temporary hostable copy. If content needs to remain structured and editable, keep that copy as a bridge and handle Framer CMS migration through source-data export, API, Markdown, or a new CMS workflow.
Decide why you are leaving
The reason determines the right destination. Common reasons include reducing a recurring cost, gaining control over hosting, moving content into a different CMS, handing maintainable code to a developer, or reducing dependence on a proprietary editor.
Write down the actual requirement. "Own the code" might mean any of the following:
- keep a working copy that can be hosted elsewhere;
- edit text and images without Framer;
- maintain clean components in a Git repository;
- control the build, server, and deployment pipeline;
- preserve the current visual site while a replacement is built.
A static export satisfies the first and last goals well. It does not automatically produce a clean React codebase or a new visual editor.
If your goal is simply to download a public website as HTML, CSS, JavaScript, and assets, the broader guide to downloading an entire website explains the general workflow. This Framer guide stays focused on Framer-specific export limits and migration decisions.
Step 1: inventory the live Framer site
List every public route and every feature that sends or stores data. Use the published site, not only the canvas.
At minimum, record:
- primary pages in the navigation;
- campaign and unlinked landing pages;
- CMS collection templates and representative entries;
- localized paths;
- forms and their destinations;
- analytics, consent, and advertising scripts;
- custom code embeds;
- redirects and domain settings;
- downloadable files and third-party widgets.
This list becomes the acceptance test for the exported copy. It also exposes the parts that no front-end exporter can make independent.
Step 2: choose static preservation or a rebuild
Use a static copy when the current design should remain intact. Typical candidates are portfolios, agency sites, product landing pages, and documentation.
Choose a rebuild when structured content in a CMS, memberships, ecommerce, or application logic is central to the site. The export can still be the live site while those systems are replaced, and you can keep editing the pages with an AI assistant.
If you want a framework codebase, plan a deliberate rebuild. The copied files are still yours in the meantime.
Step 3: make and inspect the static copy
An exporter loads the public site, follows reachable pages, saves their assets, and rewrites links for the new file structure. Open the copied site and click through it so you can decide whether the static HTML ZIP is useful.
In the copy, check:
- the desktop and mobile navigation;
- one page of every distinct layout;
- CMS-driven pages and pagination;
- overlays, accordions, carousels, and tabs;
- fonts, responsive images, and video posters;
- outbound links and downloadable documents.
Do not treat a good homepage as proof that the whole export is sound. A 25-page cap should cover most small marketing sites, but larger publications need a narrower archive or a different migration process.
This is also where a Framer-specific guide differs from a generic website downloader comparison. A listicle such as best website downloaders helps you compare tool categories. This playbook is about the migration decision after the Framer copy exists: what the export can stand in for, what must be rebuilt, and how to leave without breaking the live domain.
Step 4: replace Framer-hosted behavior
Forms
The visible fields may survive while submissions still depend on Framer. Point each form at a new endpoint and test success, validation, spam handling, error states, and email delivery. Formspree, Basin, Formspark, a serverless function, or your own API can all work. The right choice depends on volume and data sensitivity.
CMS
A static export freezes the rendered CMS entries that were public and captured. Future entries, drafts, field edits, references, and Editor-driven changes will not appear automatically. For ongoing publishing, migrate source content separately into a headless CMS, Markdown repository, WordPress, Ghost, or another system suited to your editors.
Analytics and consent
Decide whether to carry the existing tags across. This is a good moment to remove abandoned pixels. If consent rules apply, confirm that the new host still blocks optional scripts until consent rather than merely displaying a banner.
Search, memberships, and ecommerce
These are applications, not page decorations. Replace them explicitly or choose a platform that owns the whole workflow. A static copy can preserve a product page; it cannot preserve inventory logic, customer accounts, or order history.
Editor and project workflow
A static ZIP is not an editable Framer project. The files are still yours. An AI assistant can help you swap text or add a page if you do not want to hire a developer. If you want to compare adjacent builder exits, see the guides for Webflow export, Wix website download, and Squarespace website download.
Once those replacements are planned, put the static files on a host you control.
How to self-host a Framer site
Self-hosting a Framer site means serving a static copy of the published pages on a host you control. That host can be Netlify, Vercel, Cloudflare Pages, GitHub Pages, or any other static host. Framer hosting is different. It keeps the editor, CMS, and Framer-run services on Framer's infrastructure.
The ZIP is a snapshot of the published pages. It holds HTML, CSS, JavaScript, and images. It does not export Framer CMS data or the editor project. The files are yours. An AI assistant such as ChatGPT, Claude, or Cursor can help you swap text or add a page.
Published pages, styles, images, and most animations already baked into the published output keep working.
Forms, CMS editing inside Framer, Framer analytics, password pages, and localization features that depend on Framer need a replacement. Step 4 covers how to replace those.
Cloudflare Pages and GitHub Pages can serve the same folder. The steps below are for Netlify and Vercel. For other hosts, see self-host your website.
Put the files on Netlify
- Unzip the archive and find the folder that contains
index.html. - Sign in to Netlify and add a new site.
- Drag that folder onto a manual deploy, or use the Netlify CLI from that folder.
- Open the temporary hostname Netlify assigns and click through the pages you care about.
Put the files on Vercel
- Unzip the archive and find the folder that contains
index.html. - Sign in to Vercel and add a new project.
- Drag that folder onto a deploy, or use the Vercel CLI from that folder.
- Open the temporary hostname Vercel assigns and click through the same pages.
Do not change DNS yet. Use Step 5 to test this hostname. Then use Step 6 to move the domain.
Step 5: test the deployed copy before moving the domain
Keep the site on the temporary hostname from the self-hosting steps above. Test that live copy because local files and a hosted site can differ. Confirm:
- clean URLs and trailing-slash rules;
- the custom 404 page;
- HTTPS and security headers;
- redirects from old paths;
- cache behavior for HTML and versioned assets;
- form endpoints and allowed origins;
- canonical URLs, robots rules, sitemap, and social metadata.
If the exported HTML contains canonical links to the old hostname, update them before launch. Otherwise search engines may continue treating the Framer version as canonical.
Step 6: change DNS with a rollback plan
Only move the domain after the temporary deployment passes testing. Save the current DNS records and Framer configuration first. Lowering the record's time-to-live ahead of the move can make correction faster, although existing resolvers do not always honor it exactly.
After the switch, monitor the homepage, a deep route, form delivery, TLS certificate, and error logs. Keep the Framer project and subscription available during this validation window. Cancelling can wait.
Step 7: cancel the right things
Once the new site has handled production traffic, remove obsolete domain connections and cancel only the plan you no longer need. Retain:
- the downloaded ZIP;
- a copy in version control or durable object storage;
- the route and integration inventory;
- DNS records from before the move;
- any separately exported CMS data.
One archive is not a backup strategy. Store at least two copies in different systems.
FAQ
What does Framer to HTML mean?
In this guide, Framer to HTML means taking a published Framer site you own and saving the public browser output as static files: HTML, CSS, JavaScript, images, fonts, and downloadable assets. It does not mean Framer has exported the private editor project, CMS database, or a clean application codebase. Treat it as a public-site snapshot you can inspect and host, not as a native Framer source export.
Can I export Framer to HTML?
Not as a full native Framer feature that produces clean, self-hostable source for the whole site. For a public site you own, you can create a static HTML copy of the published pages and assets that browsers receive. That can work for portfolios, landing pages, and brochure sites, but it does not include Framer's editor, CMS workflow, forms backend, memberships, ecommerce, or private project data.
How do I convert a Framer site to HTML?
Use the published URL as the input. First, make a public-site snapshot and inspect the copy across key pages, responsive layouts, CMS item pages, forms, and downloads. If the copy is good enough, keep the ZIP, deploy it to a static host, replace Framer-hosted behavior, and move DNS only after the deployed copy passes testing. For the generic version of that workflow, see the guide to downloading an entire website as HTML, CSS, JavaScript, and assets.
Does Framer let you self-host?
Framer is a hosted website builder. You can point a domain at a Framer-hosted site. Framer does not give you a complete self-hostable copy of the editor and platform. You can still self-host the published front end by deploying a static copy, then replacing hosted services you still need.
Can you self-host a Framer site?
Yes. Deploy a static copy of the published pages to a host you control. Pages, styles, images, and most baked-in animations can move. Forms, Framer CMS editing, Framer analytics, password pages, and Framer localization need replacements.
Can I host a Framer site on Vercel or Netlify?
Yes. Both serve static HTML, CSS, JavaScript, and images. Drag the folder that contains index.html onto a deploy, or use the host CLI. Test on the temporary hostname before you change DNS.
Do I still need Framer hosting after I export?
No, not for the public pages once those pages are live on a host you control. Keep the Framer project online until the new host and the DNS change have been checked. You still need another home for forms, CMS editing, analytics, password pages, and localization if you use those.
What is the difference between Framer export code and a static ZIP?
"Export code" usually implies maintainable source: components, routes, styles, data models, and a build process that developers can edit. A static ZIP contains the delivered front-end files: HTML, CSS, JavaScript, images, fonts, and downloaded public assets. It can be portable and hostable without being a framework codebase.
Can I download a Framer website without project access?
If the site is public and you own or are authorized to copy it, a public-site exporter can work from the published URL because it captures browser-visible output. It cannot access private drafts, unpublished CMS entries, account data, analytics history, or the Framer project itself.
Does Framer export include CMS?
Do not treat any Framer export path as a complete CMS migration until you have checked Framer's current documentation and inspected the output. A public static copy can include rendered CMS item pages that visitors can open, but it does not include structured collections, fields, references, drafts, Editor workflow, future publishing, or private CMS data.
Can I backup Framer CMS collections?
If you need collections as data, start with Framer's current CMS export, API, or migration documentation for the account and plan you control. Then verify representative records for rich text, images, slugs, categories, authors, dates, references, and SEO fields before cancelling. A static crawl can be a useful published-page backup, but it is not the same as a structured collection backup.
Will CMS pages work after static export?
Published CMS item pages can work as static HTML if they were public, reachable, captured, and rewritten correctly. New entries, drafts, filtered views that depend on live data, Editor updates, search indexes, forms, and collection management will not keep working automatically. Test representative CMS pages in the copy before relying on the ZIP.
Does a static ZIP include CMS data?
No. A public-site copy captures the published front end: public pages, HTML, CSS, JavaScript, images, fonts, and assets that the browser can receive. It does not include Framer CMS collections as structured data, drafts, field schemas, Editor workflow, or private API dumps. Inspect the static copy first; if you need CMS data, plan a separate export, API, Markdown, or new-CMS migration.
How is this different from a website downloader list?
A website downloader list helps compare tools such as browser-based exporters, desktop crawlers, command-line mirrors, and extensions. This guide assumes the site is specifically on Framer and focuses on the exit plan: defining what "Framer export" means, testing the copied HTML, replacing Framer-hosted behavior, deploying safely, and deciding when a rebuild is the better move.
What "successfully left Framer" means
The migration is complete when the domain resolves to infrastructure you control, important routes load without Framer, required submissions reach their destination, and your team knows how future edits will be made.
The last condition is easy to skip. The files are yours, and an AI assistant can help with later edits. Hosted systems such as forms, stores, and memberships still need replacements. Decide who will update the site and how before you cancel the tool that currently supports them.
There is a Framer export page for copying published pages.