Formspree vs. Netlify Forms

Both handle the basics, and that's where the similarities end.

Both are form backends that work well for static sites. You point an HTML form at them, they email you each submission, filter out spam, and save everything to a dashboard you can look back through.

Where they differ is what happens next. Netlify Forms notifies you by email, Slack, or webhook, and anything beyond that goes through Zapier or n8n. Formspree notifies you by email, Slack, Discord, Telegram, or WhatsApp, and sends submissions straight into Google Sheets, Airtable, Notion, HubSpot, Mailchimp, Trello, and more, so you don’t need a separate automation account.

On paid plans it can also send the person who filled in the form a confirmation email, and you can write your own email templates. Netlify Forms does neither.

Netlify Forms only work on Netlify.

The whole detection mechanism runs inside the Netlify build system. When you deploy, it scans your rendered HTML for a data-netlify attribute and provisions an endpoint for each form it finds. That machinery does not exist off-platform.

If you decide next year to move to Cloudflare Pages, Vercel, or a VPS of your own, your forms don't come with you. You'd re-wire every submission handler and rewrite the backend contract from scratch. The forms belong to the Netlify platform, and they stay there when you leave it.

Formspree is a standalone endpoint. The action attribute is a URL, and the URL doesn't care where the HTML that surrounds it is served from. Move hosts as often as you like, and the form keeps working.

JavaScript forms need a workaround on Netlify.

Netlify's detection only sees markup that's in your build output. Forms rendered at runtime by React, Vue, or Svelte are not in the HTML at deploy time, so the scraper never finds them and no endpoint gets provisioned.

The documented workaround is to duplicate a hidden static version of every form into your build so the scraper picks it up, then hydrate the real interactive form over the top. If your stack is pure SSR or SSG, that's a papercut. If it's an SPA, it's ongoing work every time a field changes.

Formspree doesn't scrape anything. The endpoint URL is the form API, and it doesn't care when or how your form markup came into existence, whether server-rendered, client-rendered, hydrated later, or injected by a third-party widget. Post to the URL and it works.

Spam filtering is ongoing work.

Netlify Forms runs every submission through Akismet, and you can add a honeypot field or reCAPTCHA on top. For a personal contact form, that’s often enough.

Public forms attract more spam, and smarter spam, over time. Keeping up is an arms race that needs a filter trained on real traffic and updated as new patterns appear.

Formspree runs Formshield, its machine-learning filter, trained on the five million+ submissions we process each month and updated continuously. It comes with built-in support for reCAPTCHA, hCaptcha, and Cloudflare Turnstile, a honeypot field, and domain restrictions, and from the Professional plan you can tune its sensitivity and block whole categories of spam. It’s on us to keep it working.

Switching is a one-line change.

Both services take submissions from HTML forms. To move from Netlify Forms to Formspree, you point your HTML form's action at a Formspree endpoint and drop the data-netlify attribute. Field names stay exactly as they are.

The change is a five-minute edit per form, with your framework, templates, and hydration setup left alone. Roll it back any time.

Just use Formspree.

Netlify Forms works well if your site stays on Netlify, your forms are plain HTML, and spam is light. If any one of those things changes, you’ll need to do some workarounds.

Formspree is built for the case where the form is yours and the backend is someone else's job. It's decoupled from your host, works with any framework, prices independently, and moves with you if your stack ever changes.