Framer's native forms come with spam protection switched on, and Framer's help centre is unusually candid about its limit: "If you're still receiving spam through a form on your site, it's likely being submitted by a real person." Its advice for that case is to filter out unwanted entries manually, wherever they are stored. This post covers the settings Framer gives you, what that sentence means in practice, and two ways to put a filter that reads the message behind a Framer form. Framer details are from its help centre as of 24 October 2026.
What Framer's protection does
Spam protection is set per form. Select the Form layer, open Antispam in the right sidebar, choose a type and a filtering option, then publish. Changes only apply to submissions received after you publish.
- Basic is on by default for every site, and Framer describes it as fast, rule-based checks for common spam patterns. Separately, Framer says its forms run a captcha in the background: a mathematical puzzle the visitor's device has to solve, which bots and bot networks typically lack the computing power to do. Native forms are also rate limited.
- Advanced adds an AI layer that analyses submissions for subtler spam. It needs a Pro plan or above.
- Pass delivers everything and marks what looks suspicious: a [Spam] or [Possible Spam] prefix on the email subject, a Framer Spam Detected column reading possible or likely in Google Sheets, and X-Framer-Spam-Protection and X-Framer-Spam-Classification headers on webhook requests.
- Block stops submissions identified as spam from reaching your destinations. Framer's FAQ states the cost plainly: if a legitimate submission is flagged while Block is on, it is not delivered. Its help pages do not say whether a blocked submission is kept anywhere you can read it.
There is no native reCAPTCHA integration. Framer's help says so, and says it is exploring ways to improve its spam filtering.
Getting the most from it without leaving Framer
- Bot-shaped junk (gibberish, lists of links, the same message many times over) is what Basic is built for. If you are seeing a lot of it, check that the form is a native Framer form: Antispam is a setting on the Form layer, so a form inside an Embed is not covered by it.
- On Pro, try Advanced with Pass first. The markers show you what it would have blocked, so you can judge its mistakes before you let it drop anything.
- Use the markers. A mail rule on the [Spam] subject prefix, or a filtered view on the Sheets column, gets most of the benefit of Block without the risk of an enquiry never arriving.
- If your form sends to a webhook, branch on the X-Framer-Spam-Classification header in your own endpoint instead of discarding the request.
If that leaves a trickle you can live with, you are done. Framer's protection is reasonable, and Pass with visible markers is a sensible choice for anyone who would rather see a false positive than lose one.
Why spam still arrives: the person problem
A background puzzle answers one question: is the device on the other end a machine? The spam that survives it is the kind where the answer is no. Someone sending SEO, development or lead-generation pitches by hand solves the puzzle like any other visitor, and so does a tool that drives a real browser. Framer's suggestion of an image captcha would slow some of those senders down, but as its help says, it cannot fully prevent them.
What separates that spam from a real enquiry is the message, so only something that reads the message can catch it. On Framer, the layer meant for that is Advanced, on Pro plans. On WebForms it is a layer we decided every plan should have, the free one included, because a promotional message with no links and no blocked words trips no rule at all and reaches the inbox untouched.
What WebForms does with a message a person typed
Our filter starts with cheap deterministic signals: a honeypot, a time trap, throwaway email domains, links packed into a message, and domains or keywords you choose to block. Then an AI classifier reads the message on every submission those signals have not already condemned, including the ones they scored at zero, because that is where hand-typed spam usually ends up.
We measured it before switching it on for everyone. On 22 September 2026 we ran it over the 808 submissions WebForms had stored at that point. It agreed with 50 of the 51 that the deterministic filter had already quarantined, and it flagged 11 that had been delivered as spam with at least 90% confidence. None of those submissions had a human label, so these are agreement figures, not accuracy, and they are the only figures we have.
What happens on a hit matters as much as the hit. Framer offers two outcomes: deliver with a marker, or do not deliver. We chose a third. A submission over the spam threshold is quarantined, which means stored and readable in the dashboard, never delivered to any destination, and not counted toward your monthly submissions. If a real enquiry is held by mistake, it is still there for you to read and answer.
Two ways to put it behind a Framer form
Keep the Framer form and add a webhook
Framer forms can send to a webhook: Framer posts each submission as JSON, using your input names as keys, and retries up to five times if it does not get a 2xx response. WebForms accepts JSON at the same endpoint a form posts to, so you can paste your endpoint in as the webhook URL and keep everything about the Framer form, including its design, its states, Basic protection and rate limiting.
Form layer > Send To > Add > Webhook URL: https://send.webforms.to/wft_your_key Form layer > Antispam Type: Basic (or Advanced, on Pro) Filtering: Pass Input names name, email, message
Pass is deliberate. With Block, Framer drops what it flags before WebForms ever sees it, and Framer does not say it keeps a copy. With Pass, every submission reaches WebForms, where a false positive is quarantined and still readable. WebForms does not read Framer's spam headers, so each submission is judged afresh.
The trade-off is that the request comes from Framer's servers, not from your visitor's browser. Our honeypot and domain lock are designed for forms that post from the visitor's browser, so they add nothing on this route; Framer's puzzle does that job in front. The content checks and the classifier work the same either way. Naming the inputs name, email and message keeps notifications readable.
Or post straight from the page
The other route is the one in our Framer guide: a code component, or an Embed holding a plain HTML form whose action is your endpoint. Every WebForms check applies, including the honeypot and the domain lock, and Framer's Antispam does not, because it is a setting on the native Form layer. The code component keeps visitors on the page with a success state you design; the embed needs no code at all.
<form action="https://send.webforms.to/wft_your_key" method="POST"> <p hidden><input name="_gotcha" tabindex="-1" autocomplete="off"></p> <input name="name" required placeholder="Name"> <input name="email" type="email" required placeholder="Email"> <textarea name="message" required placeholder="Message"></textarea> <button type="submit">Send</button> </form>
Which one to choose
- Bot-shaped junk only: stay on Framer's forms with Basic. That is the job it does well.
- Hand-typed pitches, and you are on Pro: try Advanced with Pass and a mail rule before changing anything else.
- Hand-typed pitches without Pro, or you want suspected spam held and kept instead of delivered or dropped: add the WebForms webhook. It works on our free plan, which covers 300 submissions a month delivered by email.
- You want submissions in Slack, Discord or Telegram as well as your inbox, with a log of every delivery attempt: that is our Pro plan, at $5 a month.