On this page7 sections
You can convert a password-protected Framer site with Deframer by entering the site's password when you start the conversion. Deframer logs in once, the same way a visitor does on Framer's password page, and reads the site with the session that gives; the password itself is never stored, logged or put in a URL. Converting stays free, and downloading still needs proof the site is yours: publish the verification tag, enter the password again when you check it, and the download unlocks. A few things work differently, such as no side-by-side view of the original and no speed test of it.
This post covers why the password is needed, how it's handled, the steps, and what to expect. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer.
Why a protected site needs its password
When a Framer site is password-protected, Framer answers every path, including pages, robots.txt and the sitemap, with an HTTP 401 status and its password page. Nothing public points at the site's code. To a converter, the site looks empty.
That's the purpose of the protection, and Deframer doesn't try to get around it. Instead, you give it the password, and it does what a visitor does: submits the password on the site's own login page and uses the session cookie Framer returns.
Typical reasons to convert a protected site:
- a client site still in staging, protected until launch;
- an internal or partner site that will always be private;
- a site you want to move to your own host before it goes public.
How Deframer handles the password
The password is a secret of the site's owner, and the handling is designed around that.
Question | Answer |
|---|---|
Where is the password used? | Only in the request that logs in to the site's own address |
Is it stored? | No: not in the database, a job record, a file, a log, analytics or a URL |
What is kept? | Framer's session cookie, in memory, until the conversion's worker receives it, then dropped |
Who receives it? | Only the site's own address, over the same guarded connection Deframer uses to read the site |
Can it be used to guess passwords? | Attempts are limited per user, per site and per hour; Framer's own "too many attempts" response stops attempts for that site for the hour |
Because nothing is stored, a conversion that has to restart without its session (for example, if it's queued again after a server restart) stops and asks you to enter the password again, rather than keeping a copy to reuse.
Steps
1. Check the password works
Open the published site in a private browser window and log in with the password. If it doesn't work there, it won't work in Deframer.
2. Start the conversion
- Sign in to Deframer and paste the site's published address:
*.framer.website,*.framer.appor the custom domain. - When Deframer finds the site is password-protected, it asks for the password. Enter it.
- Pick the framework (Next.js by default, or TanStack Start, Astro, React Router or Vite) and the assets option.
- Convert. Converting is free, and a conversion that fails costs nothing.
A wrong password is reported straight away, before any conversion starts. Repeated wrong attempts are limited, so if you're unsure of the password, check it in a browser first rather than trying variations.
3. Review the result
The result page lists the conversion's notices as usual. Two review tools work differently for a protected site:
- The original side of the compare view isn't available, because it would need the site's session. When live previews are on, the converted project's preview still builds and you can review it on its own.
- The speed test doesn't run for a protected site, neither for the original nor for the converted preview.
After downloading, run the project locally and compare it with the original in another window, logged in, at desktop, tablet and phone widths.
4. Verify ownership
Downloading the code requires proof that the site is yours, or that you have the owner's permission. The verification works as for any site:
- Copy your personal verification tag from Deframer:
<meta name="deframer-verification" content="dfv_…">. - In Framer, open Site Settings, then Custom Code, and paste it at the end of the
<head>section. - Publish the site.
- Click Check again in Deframer, and enter the password when asked, so Deframer can read the live page behind the protection.
No credit is used until the tag is found. The verification guide covers the details and troubleshooting. Without verification, you can download for 10 credits after confirming you own the site or have permission.
5. Download
The download uses 1 credit after verification, or nothing with the lifetime deal; see pricing. It stays available for 7 days after the conversion finishes, and downloading it again is free.
What does the converted project do about the password?
Nothing. The converted project contains the site's pages, not Framer's password protection, which lives on Framer's servers. Run it anywhere and it's public unless you protect it yourself.
If the site must stay private on its new host, add protection there:
- Host-level protection. Several hosts offer password or SSO protection for deployments as a setting; check what your plan includes.
- Basic authentication in the server code. In Next.js, the project's
src/proxy.tsruns before every request, so a check of theAuthorizationheader there can require a username and password. Keep credentials in environment variables, not in the code. - An access layer in front. Services such as Cloudflare Access put a login in front of the whole site.
Also keep a private site out of search engines: set Disallow: / in public/robots.txt and add a noindex robots setting to the root layout's metadata, in addition to the login. A login stops people; noindex is a second line in case a page is ever exposed.
Agencies converting a client's protected site
The same steps apply, with the client in the loop:
- Ask the client for the password, or ask them to enter it themselves during a screen-share.
- Have the client publish your verification tag, so the download is with their permission.
- Don't keep the password in tickets or chat after the conversion; Deframer doesn't need it again unless you convert again.
The agency workflow covers permission and handover more broadly.
If something goes wrong
- "Enter the password again." The conversion lost its session, for example after being queued again. Start it again and enter the password.
- Too many attempts. Wait for the limit to reset. If Framer itself refused attempts, that lasts about an hour for that site.
- Verification not found. Make sure you published after adding the tag and entered the password when checking.
- Pages missing. Pages that require a different login (such as a members area handled by a third-party tool) aren't part of what Framer's password unlocks; Deframer reads only what the site's password grants.
FAQ
Is it safe to give Deframer my Framer site password?
The password is used only to log in to your site's own address, once per request, and is never stored, logged, or put in a URL. What remains is Framer's session cookie, held in memory until the conversion starts and then dropped.
Will the converted site still be password-protected?
No. The password protection is a Framer hosting feature, not part of the site's code. Add protection on your new host, in the project's server code, or with an access service.
Can I convert a protected site I don't own?
You can convert any site you have the password for, but you can download the code only if it's yours or its owner allows it. Verification proves that: only someone who can publish the site can add the tag.
Why can't I see the original in the compare view?
Showing the original would require the site's session, which Deframer doesn't keep. Review the converted preview on its own, then compare locally with the original open in your browser.
Do I need to unprotect the site to convert it?
No. Enter the password in Deframer instead. Removing protection would expose the site publicly, which is usually what you're trying to avoid.
