Framer supports custom code in four distinct ways: HTML embeds for third-party scripts, CSS overrides for global styles, code components in TypeScript for fully custom interactive UI, and code overrides for behavior on existing layers. Each method has a specific use case, a specific scope, and specific gotchas. This guide walks through all four with real examples, common mistakes, and the cleanest patterns to use in 2026.
The Four Ways to Add Custom Code in Framer
Most teams reach for HTML embeds first because it is the obvious entry point. That works for analytics, chat widgets, and simple iframes. For anything more, the other three methods produce cleaner, faster, and more maintainable results. Knowing which to use saves hours of debugging.
HTML embeds are global script and style injections placed in site settings or page settings. Use them for analytics, marketing tags, fonts, and verified domain ownership. They run before page render and are cached on the CDN.
Code components are full TypeScript or JavaScript files that render React components inside your site. Use them for interactive UI like calculators, configurators, and custom data visualizations. They support props that surface in the right panel as editable fields.
Code overrides are smaller TypeScript files that wrap existing layers to add behavior, like animation triggers, conditional visibility, and event handlers. Use them when you do not want a full custom component, just a tweak to a Framer-built layer. CSS overrides apply global stylesheet rules and are useful for fixing specific quirks or adding utility classes that the visual editor does not expose.
Adding HTML Embeds for Analytics and Scripts
Open Site Settings, scroll to General, and find the Custom Code section. There are four slots: head start, head end, body start, and body end. Each slot accepts arbitrary HTML, including script and style tags.
Place analytics scripts like GA4, PostHog, or Plausible in head end. Place the body of chat widgets like Intercom or Crisp in body end so they load after the rest of the page. Place font preload links in head start to give the browser an early hint. Place verification meta tags from Google Search Console or Bing in head start.
Three gotchas surface repeatedly. First, scripts that depend on the DOM being ready will fail in head start because the body has not rendered yet. Use defer or wrap in a DOMContentLoaded listener. Second, scripts that must run before page render, like consent management platforms, must go in head start to function correctly. Third, scripts placed in page-level settings only fire on that single page. Site-wide scripts belong in Site Settings, not Page Settings.
Building Code Components in TypeScript
Code components are the heaviest and most powerful escape hatch. They live in the Code section of the Framer canvas, written as React components in TypeScript. Framer wraps them in a renderer and exposes props as editable fields in the right panel.
The basic pattern starts with importing from framer and defining a function component with typed props. Above the function, add a propertyControls object that tells Framer how to render each prop in the editor. The supported control types include string, number, boolean, color, image, file, link, enum, array, and object. Framer’s documentation on property controls is the authoritative reference.
A simple example is a counter component with a target number, an animation duration, and a label. The component animates from zero to the target when it scrolls into view, using framer-motion’s useInView and animate. The right panel exposes target, duration, and label as editable fields, so non-developers can adjust without touching code.
Code components shine for: interactive calculators, custom charts using a library like Chart.js or Recharts, third-party integration UI like a Calendly widget styled to match the brand, and product configurators. They are overkill for static content. Use Framer’s native components and CMS for that.
Code Overrides for Layer Behavior
Code overrides are smaller patches that wrap existing layers. They are TypeScript files that export a function taking a component and returning an enhanced component. The most common patterns are: trigger an animation when a layer is clicked, conditionally show or hide a layer based on URL parameters, fetch data from an API and inject it into a text layer, or sync a layer’s state with an external store.
Apply a code override by selecting a layer, opening the Code section in the right panel, and choosing the override file. Multiple overrides can compose on the same layer.
The common use case our team ships often is conditional rendering based on UTM parameters. A hero subhead reads differently for visitors arriving from a paid ad versus organic search. A 30-line override reads the URL, picks the variant, and updates the text. No A/B testing tool needed, no extra latency, full SEO control. We covered the broader animation patterns in our Framer animations guide.
CSS Overrides and Global Styles
CSS overrides live in the Custom Code section of Site Settings, the same area as HTML embeds, but inside style tags. Use them for global rules that the visual editor does not expose, like custom scrollbar styling, focus ring customization for accessibility, print stylesheets, and reduced-motion media queries.
Avoid using CSS overrides to style specific layers. Framer’s class names are auto-generated and not stable across publishes. Selecting a specific layer by class name will work in development and break the next time you publish. For layer-specific styling, use Framer’s built-in style controls or a code component.
One pattern that does work safely is targeting CSS via custom data attributes that you assign through Framer’s name-to-attribute convention. If you name a layer with a special prefix, you can attach a data attribute via a small code override and target it cleanly in CSS. This is overkill for most projects.
Common Mistakes and How to Avoid Them
Three mistakes show up in every Framer codebase that grew organically without a plan. Watch for them.
First, overusing code components for things Framer’s native components handle. A custom button, a custom card, a custom hero section, all built as code components, leads to a maintenance nightmare. Non-designers cannot edit them in the visual canvas, and they slow page rendering. Reach for code components only when the visual editor cannot produce the result.
Second, putting global state in code components. Code components are isolated React trees inside Framer’s renderer. State sharing between two code components requires going through external libraries like Zustand or pulling from URL or localStorage. Plan the state architecture before building.
Third, writing inline styles instead of using design tokens. Framer exposes color and font tokens through the canvas. Code components can pull these tokens via the Framer SDK, which keeps the brand consistent if a designer changes a color. Hardcoding hex values in components creates drift. We covered the broader patterns in our Framer website design guide.
When to Skip Custom Code Entirely
Most marketing sites should ship without code components. Framer’s native components, CMS, and built-in interactions cover 90 percent of the patterns marketing teams need. Reaching for code first is a habit that slows projects.
Skip custom code if the goal is a marketing site, a blog, a portfolio, a documentation site, or a landing page. Framer ships these without code. Reach for code when you need: an interactive calculator that connects to a real API, a custom chart with live data, a product demo with synchronized animations, an embedded iframe that needs custom messaging, or a complex form that integrates with multiple backends.
If your team writes code for every project, the build time will exceed what a hand-coded React site would take. The advantage of Framer is the visual canvas. Use it.
Frequently Asked Questions
What plan do I need to add custom code in Framer?
HTML embeds and CSS overrides are available on all plans, including the free tier. Code components and code overrides require at least the Mini plan at 5 dollars per month per site. The Pro plan at 30 dollars adds advanced custom code features and higher limits.
Can I use any npm package in Framer code components?
Framer supports a curated set of npm packages, including framer-motion, react, and a number of common utilities. To use packages outside the supported set, you can import via ESM CDN URLs like esm.sh. Performance and security depend on the package, so vet anything you import.Where do I write code in Framer?
Open the Code section from the left sidebar in the canvas. Code components and code overrides live there, written in TypeScript with full IntelliSense. HTML embeds and CSS overrides live in Site Settings under Custom Code.
Can I deploy a custom backend with Framer?
Framer hosts the front-end. Backends run elsewhere, on Vercel, Cloudflare Workers, AWS, or any provider you choose. Code components fetch from your backend over HTTPS using standard fetch calls. Use environment variables in the code component for configuration.
Does custom code break Framer’s SEO?
Custom code can break SEO if it renders content client-side that should be in the initial HTML. Framer pre-renders code components on publish, so static content is indexable. Dynamic content fetched in useEffect is not in the initial HTML and may be invisible to search engines. Plan the rendering strategy.
Need a Framer build with custom code components done right, including state architecture and SEO-safe rendering? Talk to Framer Websites about your project.