Auth Plugin Code Overrides: Show and Hide Content by Login State

• Auth Plugin's Code Overrides component documents five overrides: ShowWhenAuthenticated, ShowWhenGuest, IdentityName, IdentityEmail, and TriggerSignOut.
• They apply to any Framer element, not just Auth Plugin's own components, through Framer's native Code Overrides panel.
• Two control visibility by login state, two inject identity data as text, and one turns any clickable element into a sign-out trigger.
• Code Overrides is included on every plan, including the free Basic tier, per the pricing page.
• Unlike a Protected Pages rule, which blocks an entire URL, Code Overrides works at the element level on a single shared page.

If you've already gone through the basic setup, sign-in forms, protected pages, the fundamentals are in this setup guide, this post is about the next layer: making individual elements on a page react to whether someone's logged in, without duplicating pages or writing custom code.

Code Overrides is one of Auth Plugin's components, added from the Components page in Framer like any other Auth Plugin element, though the insert list itself labels it "Auth Overrides." Once it's applied to an element, the property panel section you actually configure it from is titled "Code Overrides," matching the name used throughout this post. Same feature, different label depending on which screen you're looking at. Instead of rendering UI on the canvas the way a Sign In Form or Profile Form does, it generates a code file, AuthPluginOverrides.ts, that exposes a set of Framer code overrides you can attach to any element on your site.

The workflow, per the docs: insert Code Overrides from the Components page, select the element you want to control on the canvas, open the Code Overrides section in Framer's right-hand properties panel, choose AuthPluginOverrides as the file, then pick the specific override you want from that file. Framer applies it directly to the selected element, a text layer, a button, a container, an image, whatever you've selected.

That last part is the actual power of this component: it isn't limited to Auth Plugin's own components. A Show When Authenticated override can sit on a plain Framer text block, a stack, or a linked button, which is why it shows up in personalization work that has nothing to do with the sign-in form itself.

Four names get mentioned informally around the Auth Plugin site, but the docs page for Code Overrides documents five. Here's the complete set as confirmed on that page.

Visibility overrides

• ShowWhenAuthenticated: the element is visible only when the visitor is signed in. Applied to a nav link, a CTA, or an entire section, it hides that content from anyone who isn't logged in.
• ShowWhenGuest: the inverse. The element is visible only when the visitor is not signed in. This is what shows a "Sign up" prompt or a locked-content teaser to people who haven't authenticated yet.

Identity injection overrides

• IdentityName: replaces the element's text content with the signed-in user's full name. Put it on a text layer and it renders as that person's name wherever it sits.
• IdentityEmail: replaces the element's text content with the signed-in user's email address, the same mechanism as IdentityName, applied to a different field.

Action override

• TriggerSignOut: signs the user out when the element is clicked. This means a sign-out action isn't limited to Auth Plugin's dedicated Sign Out Button component; any clickable element, a text link, an icon, a menu item, can carry this override and trigger the same sign-out behavior.

That fifth override is easy to miss if you've only skimmed the component's description, which mentions "trigger a sign-out" alongside show/hide and name/email injection without spelling out the override name. It's a real, separate entry in AuthPluginOverrides.ts, not just a side effect of the other four.

Beyond these five, the docs page doesn't list additional overrides, conditional logic (like role-based visibility), or a way to inject other identity fields (phone number, custom signup fields, etc.) through this component. If you need role-based access rather than simple signed-in/signed-out visibility, that's handled through Protected Pages configuration, not through Code Overrides.

These solve different problems, and it's worth being clear about which one you actually need.

Protected Pages works at the URL level. It matches the current page's URL against a regex pattern and blocks access to that entire route if the visitor isn't authenticated (or doesn't have the right role, if you've configured that). It's the right tool when an entire page, /dashboard, /members/*, /account/settings, shouldn't be reachable at all by a logged-out visitor.

Code Overrides works at the element level on a page that's otherwise public. Nothing about applying ShowWhenAuthenticated to a button blocks anyone from loading the page; it just changes what renders once they're there. That makes it the right tool for a single shared page that needs to look different depending on who's viewing it, a homepage nav bar, a pricing page CTA, a landing page hero, rather than a members-only area that shouldn't be visible at all.

In practice, sites tend to use both: Protected Pages to gate the pages that should be members-only outright, and Code Overrides to personalize the pages everyone can reach.

A nav bar that changes based on login state. Apply ShowWhenAuthenticated to a "My Account" or "Dashboard" link and ShowWhenGuest to a "Sign In" / "Sign Up" pair sitting in the same nav position. Visitors see one or the other, never both, without you building two separate nav components or two separate pages.

"Welcome, [name]" text. Drop IdentityName onto a text layer in a header, a dashboard banner, or an email-style greeting block on the page, and it renders the signed-in visitor's name automatically. This use cases post covers this exact pattern for a SaaS dashboard header, and the mechanism is the same override described here.

Gated CTAs on an otherwise-public page. A pricing page or content page can show a "Start free trial" button to guests via ShowWhenGuest and swap it for a "Go to dashboard" or "Upgrade" button via ShowWhenAuthenticated in the same spot. Same layout position, different content, no duplicate page.

Premium content teasers. On a content or community page, ShowWhenAuthenticated can reveal the full article, download link, or resource, while ShowWhenGuest shows a locked preview or "Sign up for access" prompt instead. This is the pattern the private-community use case in the 5 real-world use cases post is built around.

Sign-out from anywhere. Because TriggerSignOut attaches to any clickable element, a sign-out action doesn't have to live only inside a dedicated Sign Out Button. A text link in a footer, an icon in a settings menu, or a row in a custom account dropdown can all carry the same override.

• Assuming only four overrides exist. ShowWhenAuthenticated, ShowWhenGuest, IdentityName, and IdentityEmail get referenced most often, but TriggerSignOut is a fifth, separately documented override. Skipping it means rebuilding sign-out logic that already exists.
• Using Code Overrides where Protected Pages was needed. Hiding a section with ShowWhenAuthenticated doesn't block the underlying page or its content from being reached directly; it only changes what renders in that spot. For anything that actually needs to be inaccessible to logged-out visitors, use Protected Pages instead.
• Expecting role-based logic from these overrides. All five overrides key off simple authenticated/guest state, not role or plan tier. Role-based visibility is a Protected Pages concern, not something these five overrides handle on their own.
• Not selecting the right element first. Because the override applies to whatever's selected on the canvas when you open the Code Overrides panel, applying it to the wrong layer, a parent container instead of the text block, for instance, produces a different result than intended. Double-check the selection before assigning the override.

How many overrides does Auth Plugin's Code Overrides component actually have?
Five, as documented on the Code Overrides docs page: ShowWhenAuthenticated, ShowWhenGuest, IdentityName, IdentityEmail, and TriggerSignOut.

Can Code Overrides be applied to elements that aren't Auth Plugin components?
Yes. Because it works through Framer's native Code Overrides panel, it can be applied to any element on the canvas, text layers, buttons, containers, images, not just Auth Plugin's own components.

Does Code Overrides replace Protected Pages?
No. Protected Pages blocks access to an entire URL for logged-out (or unauthorized) visitors. Code Overrides changes what renders on an element within a page that's otherwise reachable. They're complementary, not interchangeable.

Is Code Overrides available on the free plan?
Yes. Per the pricing page, Code Overrides is included on every tier, Basic, Pro, and Scale alike.

Can TriggerSignOut be added to something other than the Sign Out Button component?
Yes. Any clickable element can carry the TriggerSignOut override, a text link, an icon, a custom menu item, and it will sign the user out when clicked.

Does IdentityName or IdentityEmail work for logged-out visitors?
No. These overrides pull from the signed-in user's identity data, so they only render meaningful content when someone is authenticated. Pairing them with ShowWhenAuthenticated on the same or a related element is how that's typically handled.

Auth Plugin's Code Overrides component documents five overrides, not four: ShowWhenAuthenticated and ShowWhenGuest for visibility, IdentityName and IdentityEmail for injecting user data as text, and TriggerSignOut for turning any clickable element into a sign-out action. All five apply to any element in Framer through the native Code Overrides panel, which is what makes them useful for personalized nav bars, "Welcome, [name]" text, and gated CTAs on pages that stay otherwise public. It's included on every plan, and it solves a different problem than Protected Pages: element-level personalization on a shared page, not URL-level access control.