How to Add Custom Code to a Framer Site (2026)

Framer sells itself as a no-code website builder, and for most of what you will ever build, that promise holds. But every real project eventually hits the same moment: you need to drop in something Framer does not have a button for. A live chat widget. A Calendly booking iframe. A Google Analytics tag. A schema markup block for SEO. A custom font from a foundry that is not in the built-in list. That is when people search “how to add custom code to Framer” and discover the tool is quietly far more open than its no-code reputation suggests.

I have shipped client sites in Framer that carried analytics, a cookie banner, a booking embed, and a couple of third-party scripts, all without leaving the platform. So this is not a theory piece. It is the exact, ordered playbook I use, covering the four ways to add code (from the one-minute embed to full React components), which method fits which job, and the mistakes that silently break a live site. By the end you will know exactly where to paste your snippet and why.

The quick answer: four ways to add code, in plain English

There is no single “add code” button in Framer, because “custom code” means four different things depending on what you are trying to do. Here is the whole map in one place so you can jump straight to the right method.

1. The Embed element. Drag it onto the canvas to insert a block of HTML, an iframe, or a URL right where you want it to appear on the page. Use this for anything visual and inline: a YouTube video, a booking calendar, a map, a pricing table widget, a third-party form.
2. Site-wide custom code. Paste scripts into a “start of head” or “end of body” field in your site settings, and they load on every page. Use this for anything invisible and global: analytics, pixels, verification tags, chat widgets, cookie consent, global CSS or fonts.
3. Per-page custom code. The same head and body injection, but scoped to a single page. Use this when a script should only run on one page (a landing page pixel, a page-specific widget) instead of loading everywhere and slowing the rest of the site.
4. Code components and code overrides. Actual React and TypeScript, written in Framer’s built-in code editor, for developers who want fully custom, reusable, interactive elements or logic. This is the real “no ceiling” layer, and it is optional.

Ninety percent of people reading this need method 1 or method 2, and both take a couple of minutes. The other two are there when you outgrow the first two.

Before you paste a single line, you need a live Framer site to paste it into. Start a free Framer project and publish a real page in the next hour. No credit card required, and it is far easier to follow these steps with your own canvas open in front of you.

Before you start: prerequisites and a quick reality check

A few things to confirm before you go pasting code, because getting these wrong is the source of most “it did not work” frustration.

You need a Framer project. Obvious, but worth stating: custom code lives inside a specific site, so open the project you want to modify (or spin up a free one to test in).

Some code features publish only on a paid plan. The Embed element works while you design, but if you want site-wide script injection and a custom domain that third-party tools can verify against, plan on at least the Basic tier ($10/mo on yearly billing) or Pro ($30/mo). The exact gating of head and body injection by plan is the kind of detail that shifts, so confirm it on Framer’s live pricing page before you count on it. [VERIFY: whether head and body injection is limited to specific paid tiers.]

Know the difference between “in the canvas” and “in settings.” The Embed element goes on the canvas, visually, exactly where you place it. Site-wide code goes in your site settings and never shows on the canvas. Mixing these up is the single most common beginner mistake: people paste a Google Analytics tag into an Embed element on the page and wonder why it does nothing useful.

Have the actual snippet ready. Grab the exact code from your provider (the analytics account, the chat tool, the booking platform). Do not retype it. One missing quote or angle bracket and the whole thing fails silently.

Custom code publishes with your site, not in the editor preview. Many scripts (analytics, some widgets) will only truly fire on the published live URL, not inside Framer’s editing view. So the real test always happens after you hit publish, on the actual domain.

Method 1: Embed element (the one-minute way to drop in HTML)

This is the fastest, most common, most beginner-friendly method, and it is what you want any time the code produces something you can see on the page.

The Embed element accepts three kinds of input: raw HTML, a URL to embed, or a full iframe snippet. You place it on the canvas like any other element, and whatever you paste renders inside that box, sized and positioned by you.

Here is the exact flow.

1. Open the insert menu. On the Framer canvas, open the panel where you add elements (the same place you grab text, images, and shapes). Search for “Embed.”
2. Drag the Embed element onto the page where you want the content to appear. Drop it into a section, inside a stack, wherever it belongs in the layout.
3. Choose the input type in the properties panel on the right. You will see options for HTML, URL, and iframe. Pick the one that matches what your provider gave you. If they handed you a full <iframe ...> tag, choose iframe or HTML and paste it. If they gave you a shareable link, use URL.
4. Paste your code or link into the field. The embed will attempt to render immediately in the canvas so you can see roughly what visitors will get.
5. Size and position the embed by adjusting its width and height. Many third-party embeds need an explicit height or they collapse to nothing. If your embed disappears, set a fixed height first and troubleshoot from there.
6. Publish and test on the live URL. Some embeds behave differently live than in the editor, so always confirm on the published site.

Concrete examples that work well as embeds:

• A Calendly or Cal.com booking widget, so visitors book a call without leaving your page.
• A YouTube or Vimeo video via its iframe embed code.
• A Google Map of your business location.
• A third-party form (Typeform, Tally, a CRM form) that you would rather not rebuild in Framer’s native forms.
• A pricing table, review widget, or social feed from a SaaS tool that provides an embed snippet.

The Embed element is your default answer to “how do I put this specific thing on this specific spot.” If the code is meant to be seen, this is the method.

Method 2: Site-wide custom code (head and end-of-body injection)

This is the method for invisible, global code: the scripts that need to load on every page but do not render anything you place by hand. Analytics is the textbook case.

Framer gives you two injection points in your site settings, and understanding the difference is the whole game:

• Start of <head> tag. Code here loads early, before the page content. This is where analytics libraries, tracking pixels, site verification tags, global font links, and global CSS belong.
• End of <body> tag. Code here loads after the page content. This is where you put scripts that should run once the page is already visible, like chat widgets, cookie banners, and some third-party tools that ask to be placed “before the closing body tag.”

Providers almost always tell you which one they want. Google-style analytics tags say “paste in the head.” Chat and consent tools often say “paste before the closing body tag.” Follow their instruction literally.

The flow:

1. Open your site settings. Look for the settings area of your Framer project (not a single element’s properties, but the whole site’s configuration) and find the custom code or general section.
2. Locate the two code fields: one labeled for the start of the head, one for the end of the body.
3. Paste the provider’s snippet into the correct field. Head-level scripts (analytics, verification, global styles) go in the head field. Body-level scripts (widgets, banners) go in the end-of-body field.
4. Save the settings.
5. Publish the site. Site-wide code does not take effect until you publish, and often will not fire inside the editor at all.
6. Verify on the live domain using the provider’s own checker (the analytics real-time report, the tag assistant, the chat tool dashboard). If it does not register, the problem is almost always the wrong field, an incomplete snippet, or testing in the editor instead of the live URL.

What belongs in site-wide code, specifically:

• Web analytics (Google Analytics, Plausible, Fathom, and similar).
• Advertising pixels (Meta Pixel, Google Ads tag, TikTok pixel) so your ad campaigns can track conversions.
• Search Console or other verification tags to prove you own the domain.
• Global custom CSS wrapped in a <style> tag, when you need a style rule Framer’s panel does not expose.
• Global custom fonts loaded from a foundry via a <link> or @font-face block.
• Cookie consent and chat widgets that should appear on every page.

A note on discipline: every script here runs on every page and adds weight. Three analytics tools, a chat widget, and two pixels will measurably slow your site. Add only what you truly use, and remove what you stopped using.

Method 3: Per-page custom code (scope a script to one page)

Sometimes a script should run on exactly one page and nowhere else. A campaign-specific conversion pixel that only fires on a thank-you page. A specialized widget that only belongs on one landing page. Loading that globally through Method 2 would waste performance on every other page and can even pollute your analytics.

Framer lets you inject head and body code at the individual page level as well, using the same two-field idea (start of head, end of body) but scoped to the settings of a single page rather than the whole site.

1. Select the specific page in your project’s page list.
2. Open that page’s settings (its own settings, distinct from site-wide settings).
3. Find the custom code fields for that page.
4. Paste your page-specific snippet into the head or body field as the provider instructs.
5. Save, publish, and test on that page’s live URL only.

The mental rule is simple. If a script belongs everywhere, use site-wide code. If it belongs on one page, use per-page code. Keeping campaign pixels and one-off widgets scoped to their page keeps the rest of your site lean and your analytics clean.

If you have been treating Framer like a locked, no-code toy, this is the moment it stops being one. Open a free Framer site and try pasting a real embed and a real analytics tag yourself. Fifteen minutes of hands-on beats an afternoon of reading about it, and you will see how far past “no-code” the platform actually goes.

Method 4: Code components and code overrides (the developer layer)

This is the ceiling, and most people never need to touch it. But it is worth knowing it exists, because it is the reason serious teams can use Framer for genuinely custom work instead of graduating to hand-coding.

Framer includes a real code editor where developers can write in React and TypeScript. There are two flavors:

• Code components. Fully custom, reusable elements you build in code and then drag onto the canvas like any native Framer element. Think of a bespoke interactive pricing calculator, a custom animated chart, or a component that pulls live data from an API. Once created, a non-technical teammate can place and configure it visually.
• Code overrides. Small snippets of code you attach to an existing element to change its behavior or connect it to logic (custom interactions, state, data fetching, conditional behavior). The element stays visual; the override adds the brains.

The honest framing here matters. This layer requires actual front-end development skill. If you know React, it turns Framer into a hybrid where the marketing team designs visually and a developer extends with code, which is a genuinely powerful combination. If you do not code, you will almost never reach for this, and that is completely fine. Methods 1 through 3 cover the overwhelming majority of “custom code” needs (analytics, embeds, widgets, pixels, fonts) without writing a single line of your own logic.

So treat code components as the “when you outgrow embeds” option, not as a hoop you have to jump through. Most sites live happily in the first three methods forever.

Which method for which job: a quick decision table

When you are staring at a snippet and not sure where it goes, this table is the whole decision in one glance.

What you are adding	Best method	Where it goes
Analytics (GA, Plausible, Fathom)	Site-wide code	Start of <head>
Ad pixel (Meta, Google, TikTok)	Site-wide code	Start of <head>
Domain verification tag	Site-wide code	Start of <head>
Chat widget (site-wide)	Site-wide code	End of <body>
Cookie consent banner	Site-wide code	End of <body>
Global custom font or CSS	Site-wide code	Start of <head>
Booking calendar (visible on page)	Embed element	On the canvas
YouTube or Vimeo video	Embed element	On the canvas
Google Map	Embed element	On the canvas
Third-party form (Typeform, Tally)	Embed element	On the canvas
Conversion pixel on one page only	Per-page code	That page’s head or body
Custom interactive element with logic	Code component	Built in the code editor
Custom behavior on an existing element	Code override	Attached to the element

If you remember only one rule: visible and inline goes in an Embed; invisible and global goes in site settings. That single distinction resolves most confusion.

Troubleshooting: why your code is not working

Custom code fails quietly, which is maddening. Here are the actual causes, in the order I check them.

You are testing in the editor, not the live site. This is the number one cause. Most scripts (analytics, many widgets) only fire on the published URL. Publish, then open the real domain, then test. If you check analytics real-time while editing in Framer, you will see nothing and wrongly assume the tag is broken.

Wrong field. A body-level script pasted into the head field, or vice versa, can fail or misbehave. Re-read the provider’s instruction (“paste in the head” versus “before the closing body tag”) and match it exactly.

Incomplete or malformed snippet. A missing closing tag, a stray character, or copying only half the snippet breaks everything. Delete what you pasted and copy the full block again straight from the source.

An embed with no height collapses. Many iframes and HTML embeds need an explicit height or they render as a zero-pixel box you cannot see. Give the Embed element a fixed height and confirm the content appears before you fine-tune.

Content Security or cross-origin restrictions. Some third-party embeds refuse to load inside another site, or require settings on the provider’s side (allowing your domain). If a widget works on the provider’s page but not on yours, check whether they need your live domain added to an allowlist.

Plan gating. If site-wide injection is not saving or publishing, confirm your plan supports it. Free-plan limits are a common surprise. [VERIFY: exact plan requirement for head/body injection.]

Ad blockers and consent. Analytics and pixels are routinely blocked by browser extensions and privacy settings. If your own browser shows nothing, test in a clean browser or incognito window without blockers before concluding the tag is broken.

Caching. After publishing, your browser may still show an old version. Hard-refresh (or open the live URL in a private window) to see the current published state.

Work down that list and you will catch the cause almost every time.

Best practices for custom code in Framer

Adding code is easy. Adding it responsibly is what keeps a site fast, secure, and maintainable.

• Add only code you actually use. Every global script is a performance tax. Remove abandoned pixels and tools. A bloated head is a slow site.
• Prefer a tag manager for many tags. If you find yourself pasting five analytics and ad scripts, load a single tag manager container in the head and manage the rest inside it. One script in Framer, many tags controlled elsewhere.
• Only paste code from sources you trust. Custom code runs with full access to your page. A sketchy snippet can hijack your site or steal form data. Use official code from reputable providers, and read what you are pasting.
• Comment what you add. Leave a short note in the code (or a personal doc) recording what each block is and why it is there. Six months later, “what is this random script” is a real problem.
• Test on mobile too. An embed that looks fine on desktop can overflow on a phone. Check your responsive breakpoints after adding any visible embed.
• Respect privacy law. If you add analytics or pixels, you likely need a cookie consent mechanism and a privacy policy, depending on your audience and region. Do not bolt on tracking and ignore the compliance side.
• Keep a backup mindset. Framer’s version history helps, but before pasting anything risky into a live client site, know how you would remove it fast if it breaks the page.

Common mistakes and when NOT to reach for custom code

Custom code is a power tool, and like any power tool, the failure mode is using it when you did not need to.

• Rebuilding what Framer already does natively. Framer has native forms, native animations, native SEO meta fields, and responsive controls. Do not paste a third-party form or a hand-coded animation when the built-in feature does the job cleaner and faster. Reach for code only when the native tool genuinely cannot do it.
• Putting an analytics tag in an Embed element. An invisible global script does not belong on the canvas. It belongs in site settings. This mix-up is extremely common.
• Loading heavy scripts globally that only one page needs. Scope campaign pixels and page-specific widgets to that page with per-page code, not site-wide.
• Pasting unverified code from a random tutorial. If you cannot see the source and understand roughly what it does, do not run it on a live site.
• Forgetting to publish, then declaring it broken. Say it with me: custom code takes effect on the published site.
• Stacking so many tools the site crawls. Each widget, chat bubble, and pixel adds load. Audit periodically and cut what you no longer use.

The honest takeaway: custom code exists to extend Framer where it stops, not to replace the parts of Framer that already work well. Use the native feature first, and drop to code only when you hit a real wall.

Frequently asked questions

Can you add custom code to Framer on the free plan? You can use the Embed element while designing, but publishing a site with site-wide head and body injection and a verifiable custom domain generally points you to a paid plan. Confirm current gating on Framer’s live pricing page, since these limits change. [VERIFY]

Where do I paste a Google Analytics tag in Framer? In your site settings, in the “start of head” custom code field, not in an Embed element on the page. Then publish and check the analytics real-time report on your live URL, not in the editor.

How do I embed a YouTube video in Framer? Use the Embed element. Drag it onto the canvas, choose the HTML or iframe input, paste YouTube’s embed code (or use the URL option with the video link), then size the box. It renders inline where you placed it.

Can I add custom CSS to a Framer site? Yes. Wrap your CSS in a <style> tag and paste it into the site-wide head field for global styles. For most styling, though, Framer’s visual controls are faster and cleaner, so use custom CSS only for rules the panel does not expose.

Does custom code hurt my SEO or site speed? Only if you overload it. A couple of well-chosen scripts are fine. A dozen tracking tools, chat widgets, and heavy embeds will slow your pages and can hurt Core Web Vitals. Add sparingly, prefer a tag manager, and audit regularly.

Why is my embed showing up blank in Framer? Most often the Embed element has no height and collapsed to nothing, or the content only loads on the published site. Set a fixed height, publish, and test on the live URL. Also check whether the provider restricts embedding on external domains.

Do I need to know how to code to add custom code to Framer? No, not for the common cases. Embeds, analytics, pixels, widgets, and fonts are all copy-and-paste from your provider. Only code components and code overrides require real React and TypeScript skill, and most sites never need them.

Can I add a chat widget or cookie banner to every page? Yes. Paste the provider’s snippet into the end-of-body field in your site-wide custom code settings, save, and publish. It will then load on every page.

The bottom line

Framer looks like a closed no-code tool and behaves like an open one. For the vast majority of “I need to add this thing” moments, you have two dead-simple options: drop an Embed element on the canvas for anything visible, or paste into the site-wide head or body fields for anything global and invisible. Scope one-off scripts to a single page with per-page code, and when you genuinely outgrow all of that, the code components and overrides layer gives developers a real ceiling made of React.

The whole thing comes down to one question every time you hold a snippet: is this meant to be seen on the page, or to run in the background? Answer that, pick the matching method, publish, and verify on the live URL. That is the entire discipline.

The best way to internalize this is to do it once. Create a free Framer site now, drop in an embed, paste an analytics tag into your site settings, publish, and watch it fire on the live URL. Once you have done it a single time, “how do I add custom code to Framer” stops being a question forever.

---

Plan names, pricing, and custom-code capabilities cited here reflect Framer as of July 2026. Features and plan gating change over time, so confirm the current details on framer.com and framer.com/pricing before you rely on them.