Point any HTML form at one endpoint. 500 free submissions — no card, no time limit — and unlimited forms.
Create free accountWhy Webflow forms break
A native Webflow form only runs on the published site. Nothing submits from the Designer preview (the eye icon), and the two publish targets — your .webflow.io staging subdomain and your custom domain — are separate checkboxes in the Publish dialog. Submissions are then stored against your site plan, which carries a capped allowance, and notification emails go to whatever address is set under Site settings → Forms. Each of those steps is a place where a form can quietly stop working while looking perfectly fine in the Designer.
The fastest way to split the problem in two: open Site settings → Forms and look for your test submission. If the entry is there, the form works and only the email leg is broken. If it is not there, the submission never reached Webflow at all, and the fixes below are ordered to find out why.
Quick checklist
- You tested on the published URL, not the Designer preview.
- The site is published to the domain you tested on — staging and custom domains are separate checkboxes.
- Your test entry appears (or does not appear) in Site settings → Forms.
- The notification email address under Site settings → Forms is an inbox you actually read.
- You are under the site plan's submission allowance.
- reCAPTCHA, if enabled, is configured for this site and domain.
- If the form has a custom Action, Method is set to POST and the URL is current.
- The browser console shows no errors when you submit.
Eight fixes, in order
1. Publish to the right domain
Forms do not submit from the Designer preview, so a form that "does nothing" in the Designer is behaving normally — publish and test on the live URL. The common real-world version of this bug: the form works on yoursite.webflow.io but not on the custom domain, because only the staging checkbox was ticked in the Publish dialog. Publishing to one domain never publishes to the other. Open Publish, tick every domain you intend to serve, and publish again.
Two related traps. First, after editing the form, the old published version keeps serving until you publish again — retest on the URL you just published. Second, if the form is a native Form Block with a custom Action pointing at an external backend, test that configuration on the custom domain: on the .webflow.io staging URL, Webflow can still intercept the native block's submission, so a staging test does not tell you what your backend receives. An Embed-element HTML form behaves differently — the browser posts it directly, so it can be tested on either published URL.
2. Check the site plan's submission limit
Native Webflow submissions are capped by the site plan — a lifetime total on the free tier and a monthly allowance on paid plans. When the cap is reached, Webflow stops storing new entries and sending notifications, but the visitor still sees your success state. Nothing warns either side. Check usage under Site settings → Forms before debugging anything else; the current figures for your plan are stated there.
Spam counts against the same allowance, so a bot flood can burn a month's submissions in days and leave genuine enquiries unstored. Deleting old entries frees space in the interface but does not refund a lifetime allowance on the free tier. If you are at or near the cap, the durable fix is fix 8 below: point the form at an external backend and Webflow's counter leaves the path entirely. The full breakdown of the caps and how to check usage is in the Webflow form submission limits guide.
3. Check the notification email address and the spam folder
If submissions appear in Site settings → Forms but no email arrives, the form is fine and the email leg is broken. Confirm the notification address under Site settings → Forms is the inbox you actually read — it is often an old address, a departed employee's mailbox, or a shared inbox nobody monitors. Check that mailbox's spam/junk folder and any server-side filters or forwarding rules before changing anything.
On lower site plans, users have also reported submissions sitting in the dashboard without the notification email ever arriving, even though the address is correct. If that is your pattern, treat email-only notification as unreliable on your tier and move the form to an external backend (fix 8) that stores every accepted submission in a dashboard before attempting the email. For the deliverability side — why notification mail lands in spam and how to fix authentication — see why contact form emails go to spam.
4. Check Webflow's reCAPTCHA settings
If reCAPTCHA is enabled for the site, a key mismatch blocks real visitors, not just bots. Keys are configured under Site settings → Forms: if they were copied from a different project, rotated in Google's console, or issued for a different domain, verification fails and legitimate submits are rejected — often with no obvious message on the form. Re-check the keys against the Google project for this site and domain, and to confirm this is your bug, switch reCAPTCHA off, republish, and resubmit. If the form then works, the keys are the problem; if it still fails, move on to the next fix.
One important boundary: Webflow's built-in reCAPTCHA only protects native Form Blocks. It does nothing for an HTML form inside an Embed element, so it cannot be the reason an Embed form fails — and enabling it will not protect an Embed form from spam either. Embed forms need their own protection, such as a honeypot field plus spam filtering at the backend.
5. Check custom code and any custom form action
If someone set a custom Action on the form, the submission goes wherever that URL points — including an old endpoint that no longer exists, a URL with a typo, or a staging address. Open the form's Settings panel and verify the Action and Method. Method matters more than it looks: endpoints expect POST, and a form set to GET sends the fields as URL query parameters instead, which the endpoint typically rejects with a 405 Method Not Allowed error.
Custom code can divert the submit just as easily. A page script that intercepts submit, calls preventDefault(), and posts with fetch() completely replaces Webflow's native handling — if that script errors, posts to the wrong URL, or sends JSON the endpoint does not accept, the submission dies inside your own code. And because a fetch() POST to another origin goes through the browser's CORS checks, a cross-origin endpoint that does not allow your domain will be blocked before the request is sent; the CORS form submission fix walks through that case. A plain form POST with no JavaScript intercept does not trigger CORS at all, so a CORS error means something is submitting via script.
6. Check forms inside CMS Collection Lists, components and repeated instances
Forms in these containers fail in ways that have nothing to do with Webflow's backend. Every form is identified by its form name, so if the same form appears in a Collection List, a component used on several pages, or several times on one page, submissions from all instances are grouped under that one name in Site settings → Forms. That is normal — but it means a "missing" submission may be filed under a shared name, and renaming the form in one instance can split what you expected to be one list.
Edit at the source: a form inside a component or a Collection Page template is changed by editing the component or template, then republishing every page that uses it. The subtler failure is a required field that is hidden — inside an unselected tab, a later step of a multi-step form, or conditionally visible content. The browser refuses to submit, tries to focus the invisible field, and the visitor sees a form that simply does nothing. Make hidden required fields optional, or reveal them before validation runs, and always test the actual published page or collection item rather than the Designer canvas, where the hidden state may not apply.
7. Check JavaScript errors from custom embeds and page code
Open the published page, open your browser's DevTools console, and submit the form. Red errors at that moment are your suspects. A throwing script elsewhere on the page does not normally break a native Webflow form — Webflow's own submit handling is separate — but a script that attaches its own submit listener with preventDefault(), rewrites the form's markup, or nests a second <form> inside the first one will. Nested form tags are invalid HTML, and browsers handle them unpredictably, so an Embed form placed inside a native Form Block wrapper is a classic self-inflicted break.
To isolate it, remove the page's custom code and Embed scripts one at a time and resubmit after each removal. The moment the form starts working, the last script you removed is the culprit — fix or delete it rather than layering workarounds on top. Also retest in a private/incognito window to rule out browser extensions, and test on a second browser: a form that fails in one browser only is almost never a Webflow or plan problem.
8. Send Webflow forms to an external backend
If the form keeps breaking at Webflow's limits, email reliability, or spam filtering, take Webflow out of the submission path while keeping the design exactly as built. For a native Form Block, select the form, open Form Settings, set Action to https://splitforms.com/api/submit and Method to POST, then add a hidden field carrying your access key:
<input type="hidden" name="access_key" value="YOUR_ACCESS_KEY" />Give every visible field a sensible name in the settings panel (email, name, message) — those names become the labels in the notification email, and Webflow's default names produce unreadable notifications. Test the native block on your custom domain, since Webflow can intercept a native block's custom action on the .webflow.io staging URL. If you need fields the native block does not support, use an Embed element with a plain HTML form posting to the same endpoint instead.
With splitforms, accepted submissions are saved to a searchable dashboard before the owner notification email is attempted, spam is filtered with a honeypot plus rule-based scoring, and notification email is included on every plan — free for 500 submissions total, then $5/month for 5,000 a month. Because submissions no longer pass through Webflow's handler, the site-plan cap and its silent failure mode stop applying. The full walkthrough, including the Embed-element route and styling with your Webflow classes, is in how to add a contact form to Webflow.
Other form problems and fixes
- Contact form not working
- HTML form not submitting
- Form submission canceled (form not connected)
- 405 Method Not Allowed
- 401 Unauthorized
- CORS error
- Form sends but no email arrives
- Emails land in spam
- Elementor form not sending
- Gravity Forms not sending
- WPForms not sending
- Ninja Forms not sending
- mailto: action not working
- Works in preview but not live
- Netlify form not working
- Wix form not working
- Required attribute not working
- input type=number maxlength not working
- autocomplete="off" not working
- Form resubmission on refresh
- Duplicate form submissions
Still stuck? Test your endpoint with our free Form Action Tester or contact splitforms support.
FAQ
Why does my Webflow form work on webflow.io but not on my custom domain?
Almost always because you published only to the staging subdomain. In the Publish dialog, both domains need their checkboxes ticked — publishing to yoursite.webflow.io does not automatically publish to your custom domain. Open Publish, tick the custom domain, and publish again. If the form is a native Form Block with a custom Action pointing at an external backend, also test on the custom domain: on .webflow.io, Webflow can still intercept the native block's submission, so a staging test will not show you what the external endpoint receives.
Where do Webflow form submissions go?
Native Webflow submissions are listed in the Designer under Site settings → Forms, grouped by form name. That list is the first place to check: if your test entry is there, the form submitted fine and only the notification email is missing. If it is not there, the submission never reached Webflow — most commonly because the site was not published to that domain, the plan's submission allowance is used up, or a custom Action or script is diverting the submit.
Why does my Webflow form show success but nothing is stored?
Because hitting the site plan's submission allowance fails silently: the visitor still sees your success state, but Webflow stops storing entries and sending notifications. Check your usage under Site settings → Forms before assuming anything else is broken. Spam submissions count against the same allowance, so a bot flood can use it up. The durable fix is to point the form's Action at an external form backend, so Webflow's counter is no longer in the path.
Does Webflow's reCAPTCHA protect an Embed-element form?
No. Webflow's built-in reCAPTCHA only protects native Form Blocks, so toggling it on will not guard an HTML form pasted into an Embed element — and misconfigured keys will not block that form either. If an Embed form itself is failing, look at its own action URL and any scripts on the page instead. Embed forms still need their own spam protection, such as a honeypot field plus server-side spam filtering at the backend.
Can I keep my Webflow form after hitting the submission limit?
Yes, without changing hosting or your design. Select the native Form Block, open its Form Settings, set the Action to an external endpoint such as https://splitforms.com/api/submit with Method set to POST, and add a hidden field carrying your access key. Submissions then go straight to that backend and no longer count against Webflow's plan allowance. The step-by-step walkthrough for both the native block and the Embed-element route is in the guide to adding a contact form to Webflow.
Stop fighting plan caps and silent failures — point your Webflow form at https://splitforms.com/api/submit and every submission is stored, filtered, and emailed. Get a free access key.
Related: add a contact form to Webflow, the Webflow contact form guide, and the free contact form.