Feature Requests

Allow users to password protect individual pages, rather than entire sites.

Currently, you can't use the lightbox effect for images added inside a formatted text field. It would be useful if it could be done.

while browsing through the marketplace page, if i open up a component, i cannot go back to the main page as there is no back button.

While optimizing performance in Framer projects, I noticed there is currently no way to control the fetch priority of images in the UI. Fetch priority is critical for improving Largest Contentful Paint (LCP), especially for images that appear above the fold. Without control over this, important images may not load as quickly as they should, negatively impacting performance and user experience. Proposed Feature: UI Support (Image Settings Panel)(See Attached Image) Add a toggle option in the Image (Fill) settings: Fetch Priority Toggle (Default: Off) ON → fetchpriority="high" OFF → default browser behavior Helper text: “Enable this for above-the-fold images to improve loading performance and reduce LCP.” Code Component Support Extend ControlType.ResponsiveImage to include fetch priority as a prop, so developers can control it in custom components as well. export function MyComponent(props) { return ( <img src={props.image.src} srcSet={props.image.srcSet} alt={props.image.alt} fetchpriority={props.image.fetchPriority} /> ) } addPropertyControls(MyComponent, { image: { type: ControlType.ResponsiveImage, } }) This would allow: Keeping parity between Framer UI and Code Components Better flexibility for advanced use cases Use Cases: Hero images and landing visuals Above-the-fold banners Performance-critical assets Why This Matters: This feature would significantly improve performance optimization capabilities in Framer: Helps reduce LCP (Core Web Vitals) Gives users control without relying on hacks like overrides Aligns Framer with modern browser standards Current Limitation: No way to control fetch priority in UI No support in ControlType.ResponsiveImage Forces developers to rely on workarounds like overrides or ignore optimization opportunities Summary: Adding fetch priority support across both Framer UI and Code Components would be a small but highly impactful improvement for performance-focused users.

While working with viewport triggers in Framer, I noticed that the “Section in View” trigger behaves differently depending on where it is used - specifically between Scroll Animation Effects and Text Effects. Although both use the same naming, the actual trigger point differs: Scroll Animation Effects → calculated based on the section/container Text Effects → calculated based on the text layer’s bounds within the section This difference is not immediately obvious, and since both use the same label, it creates confusion when trying to predict when an animation or effect will trigger. Problem: The same trigger name (“Section in View”) suggests consistent behavior, but in practice: It fires at different moments depending on the effect type There is no visual feedback to indicate the trigger boundaries Users have to rely on trial and error to understand behavior This can lead to unexpected results, especially when combining scroll animations and text effects in the same section. Proposed Feature: Option 1: Add Visual Viewport Preview Show a visual indicator of the trigger area (e.g., overlay lines or highlighted zones) Display this on hover or when the trigger is selected Clearly represent when the trigger will fire relative to the viewport Or add a (i) button with video in the section-in-view trigger setting for these triggers top/middle/bottom. Option 2: Clarify Trigger Context Rename triggers to reflect their behavior more clearly, such as: “Section in View (Container-based)” “Section in View (Element-based)” Option 3: Unified Behavior (Optional) Provide an option to standardize how triggers are calculated across effects Use Cases: Designing precise scroll-based animations Synchronizing text effects with section animations Reducing guesswork when building complex interactions Improving learning experience for new users Why This Matters: Framer’s visual development approach is powerful, but interactions like viewport triggers should be intuitive and predictable. Adding a visual preview or clarifying behavior would: Reduce confusion and debugging time Improve consistency across features Help users better understand how their animations behave Enhance overall UX for both beginners and advanced users

When managing CMS collections across many locales 20/30+, teams need a one-click way to make an article visible in only one locale without manually toggling “Hide in this locale” for every other locale.

I offer multiple services that I would like to collect data on in the native form app. It would be helpful to have the ability to select multiple options like a checkbox section with a title (like the radio selection, but checkboxes).

It would be super useful to have support for variables, similar to what Figma offers. Being able to attach specified values to things like padding, gap, or basically anywhere that allows a numerical input would enable a lot of systematic structure that's currently not natively possible. It could work similarly to how text style sizing works, where its possible to define a size based on the breakpoint. Variables could allow for a layer of abstraction in defining consistent system-wide values, such as "padding-large" being set to 128px on desktop and 64px on mobile, for example. This would make updating values across all pages much easier.

I don't have an organization. I have access to a bunch of different people's workspaces. I have no idea why, or how. Maybe it's my email? Help please! I have no idea what happened.

setCustomCode only supports 4 site-level slots, but the UI allows scoping custom code to specific pages. Please expose this in the API as well. Use case: Programmatically managing per-page JSON-LD for SEO/LLM discoverability across 100+ static pages. Without page-level targeting, the only workaround is JS-based injection, which isn't visible to crawlers that don't execute JavaScript.