PageLock vs JavaScript
Password Protection
Most Framer password components don't actually protect your content - it still ships to the browser. Here's why JavaScript protection fails and how PageLock solves it.
The Security Comparison
How JavaScript Protection Fails
Anyone with basic technical knowledge can bypass it
View Page Source
Right-click, "View Source" and scroll down. Your "protected" content is right there in the HTML, hidden by CSS.
Browser DevTools
Press F12, find the hidden div, change display:none to display:block. Done in under 30 seconds.
Disable JavaScript
Turn off JavaScript in browser settings. Many JS protections simply fail and show everything.
Find Password in Code
The password is often stored in the JavaScript itself. Search the source for common variable names.
How PageLock Actually Works
Server-side protection that cannot be bypassed by disabling JavaScript or viewing source
Content Stored Server-Side
When you protect a page, the actual content is removed from the published page and stored on Proofly servers.
Original Page Shows Login
The original URL now only contains the login form. There's no hidden content - it literally isn't there.
Server Validates & Serves
After correct authentication, the server retrieves and displays your content. Never exposed until verified.
What Server-Side Protection Actually Means
The phrase gets used loosely, so here is the concrete mechanism. When you protect a page with PageLock, the plugin removes the protected content from the page Framer publishes and stores it on Proofly servers. What ships to every visitor is a page containing only the login form. There is no hidden div, no display:none, no encrypted blob waiting in the bundle: the content is not on the client at all.
When a visitor logs in, the credential goes to the server, the server verifies it against a salted hash, and only then does the server return the protected content for that authenticated session. That order of operations is the entire security difference. A JavaScript gate makes the browser promise not to show content it already has; a server-side gate never hands the content over in the first place.
This is also why the usual bypass tricks fail against it. Disabling JavaScript leaves you with a login form. View Source shows a login form. DevTools shows a login form. A scraper fetches a login form. The content simply is not there to find, and no amount of client-side cleverness changes what the server refuses to send.
The Other Alternatives
JavaScript overlays are not the only alternative to PageLock. Here is where the rest of the field lands.
Framer's built-in site password
Genuinely secure, because Framer enforces it server-side, but it is all or nothing: one shared password gates the entire site. You cannot keep your homepage public while protecting one page, and you cannot give different people different credentials. Details in the password protection guide.
Membership platforms
Memberstack and Outseta add real accounts and billing, and their gating is legitimate. The tradeoff is scope: platform pricing and platform setup for what is sometimes just one locked page. See PageLock vs Memberstack.
Hiding pages from navigation
Removing a page from the menu is not protection. The URL still works for anyone who has it, search engines can still find it, and link previews can leak it. Obscurity fails silently, which makes it worse than an honest overlay.
Moving content off Framer
Some teams put private content in Notion or Drive instead. It works, but now your client experience lives off-brand and off-domain, and link-based sharing is one forward away from public.
Migrating From a JavaScript Gate
Already shipped an overlay-protected page? Switching takes a few minutes:
Remove the overlay component
Delete the password component or code override from the page in Framer.
Lock the page with PageLock
Create a lock in the dashboard, run the plugin on the same page, publish.
Verify the fix
Open the published page, View Source, and search for your protected text. With a server-side gate it is simply not there. Our free security checker automates this test.
Common Questions
Why do people use JavaScript protection if it's insecure?
Because it's easy to build and looks like it works. Most people never test the security - they see a password prompt and assume it's protected.
Is PageLock harder to set up?
No! The setup is just as simple - create a lock, run the plugin. The security difference happens behind the scenes.
Does PageLock slow down my site?
The login check adds milliseconds. Once authenticated, content loads at normal Framer speeds. You won't notice any difference.
Can I migrate from a JavaScript solution?
Yes! Simply remove the old component, run the PageLock plugin on the same page, and you'll have real protection.
How do I test whether my current protection is real?
Open your protected page in a private window and use View Source to search for the protected text, or run our free security checker. If the content appears in the page source before you log in, the protection is visual only.
Keep reading
See everything the plugin does on the PageLock product page, or follow the step-by-step guide to password protecting a Framer page.
Ready for Real Security?
Switch to server-side protection today. Free on staging domains, no credit card required.
Get Started Free