Contact form for Framer websites

Open the Code Components panel in Framer (sidebar → Components → New Code Component). Paste the snippet above. Save. The component appears in the Insert menu — drag it onto any frame. Set the accessKey property in the right panel.

Yes. Framer's published sites are static React + JS, and Code Components run in the browser. The form posts directly to splitforms.com — no Framer-side configuration beyond the Code Component itself.

Use a status state with four values (idle/loading/ok/err) inside the Code Component. Render error messages from the splitforms response. Style them with inline styles since Framer's CSS modules don't apply inside Code Components.

Not directly — Framer's built-in form widget posts to Framer's backend. Replace it with the Code Component to use splitforms. The Code Component renders inside Framer just like a native widget.

Two options. (1) Render an inline success message or set window.location after a successful fetch. (2) For a native form post, add a hidden redirect field to the Code Component pointing at your thank-you URL — free on every plan — or configure a default in Dashboard → Form settings → Redirect.

Yes — both. Framer's preview executes Code Components (so you can test the form in the editor), and the published site embeds them as React components. Splitforms-side, lock the access key to both your *.framer.app domain and your custom domain.

Yes. In the Framer editor use Insert → Embed and choose HTML, then paste a plain splitforms <form> (or a self-contained iframe with the form in its srcdoc). This drops an Embed component onto the canvas wherever the form should live — a contact section, a footer, or a dedicated Contact page. The form posts straight to splitforms with no external scripts, and the hidden honeypot field still stops bots. The Code Component route is better when you want property controls and inline success states; the Embed route needs zero React knowledge.

Framer reads property controls only if addPropertyControls(Component, {...}) is called after the component is exported. If you put it before the export or wrap it in a conditional, the access-key control disappears from the right panel and you can't set the key visually.

Editing the access key in the right panel re-mounts the form mid-edit. If a user is testing the form when you change the key, their status === 'loading' state resets to 'idle' visually but the in-flight fetch still completes. Not a bug in production — only an editor quirk.

Framer's published sites have a default Content Security Policy that allows known integrations. Splitforms isn't on the default allowlist — you may need to add connect-src https://splitforms.com via Framer's Site Settings → Custom Code → Head HTML, inside a <meta http-equiv="Content-Security-Policy" content="…"> tag.

If you use style={{ fontFamily: '...' }} in a Code Component, you have to import the font manually — Framer's site fonts only auto-apply to canvas-built elements. Use font-family: inherit to inherit from the parent frame.

Browser-default focus rings are sometimes hidden by Framer's reset CSS. Add :focus { outline: 2px solid currentColor; outline-offset: 2px; } in your component's styles — accessibility requires a visible focus indicator.

If your contact form Code Component lives inside a Smart Component variant (e.g. a 'Mobile' variant of a header), Framer re-instantiates the entire Code Component when switching variants — losing your useState for status. A user mid-submission who rotates their device sees the form reset to 'idle' while the fetch is still in flight, then a stale success/error notification when the request resolves into a now-unmounted component (React logs a 'state update on unmounted component' warning). Either lift the form out of any Smart Component variant, or persist status to sessionStorage and rehydrate on mount.

Framer's built-in form widget delivers submissions to a single email address (configured per form) with no dashboard for managing submissions, no webhooks below the Pro plan, and no spam filtering beyond Framer's basic bot detection. CMS-driven Framer forms inherit the same constraints. The native flow works for a portfolio's contact form; it falls apart for any setup that needs Slack/Discord notifications, multiple recipients, CSV export, or tagged form-name routing. Replacing it means writing a Code Component — Framer's mechanism for embedding custom React. That's the pattern splitforms uses: a Code Component with the access key as a property control, dropped onto the canvas like a native widget.

Framer publishes sites to its own CDN — there's no Vercel/Netlify config to manage. The form posts cross-origin to splitforms regardless. Framer's published sites have a default Content Security Policy that may block connect-src to splitforms.com on some plans; if submissions silently fail, add <meta http-equiv="Content-Security-Policy" content="connect-src https://splitforms.com"> via Site Settings → Custom Code → Head HTML. Lock the access key to BOTH your *.framer.app preview URL AND your custom domain — Framer serves both with different Origin headers. Framer's preview environment runs Code Components live, so you can test the form before publishing.