Where Do Form Submissions Go? (Beginner's Guide 2026)

The journey of a form submission, start to finish

When someone fills in your contact form and clicks submit, the data makes a short, well-defined trip. Understanding the four stops on that trip answers almost every "where did my message go?" question you'll ever have.

1. The browser packages the data. Every input inside the <form> tag that has a name attribute gets collected into name/value pairs. No name attribute, no data — a field without a name is invisible to the submission.
2. The browser sends it to the action URL. The form's action attribute is the destination address, and method="POST" is the verb. This is a plain HTTP request, the same mechanism as loading any page — except it carries your visitor's answers in the body.
3. A server receives and processes it. Whatever lives at the action URL — a WordPress plugin, a hosted form endpoint, your own API route — parses the data, hopefully checks it for spam, and decides what to do with it.
4. The data lands in storage and/or your inbox. Good systems do both: write the submission to a database you can browse later, then send you an email notification. Email-only systems skip storage, which works right up until an email gets lost.

That's the entire system. Every form on the internet — Google Forms, your bank's login page, a Webflow contact form — is a variation of these four steps. The differences are just whose server sits at step 3 and which destinations are wired up at step 4.

The action URL decides everything

If you remember one thing from this post: the action attribute is the shipping address for your form's data.

<form action="https://splitforms.com/api/submit" method="POST">
  <!-- data from these fields will be POSTed to that URL -->
  <input type="email" name="email" required />
  <textarea name="message"></textarea>
  <button type="submit">Send</button>
</form>

Change the action URL and you change where every future submission goes — without touching anything else about the form. The page can be hosted anywhere (GitHub Pages, Vercel, a WordPress server, an old shared host); the action URL is independent of the page's host. For the full anatomy of this attribute, including relative URLs and method quirks, see the HTML form action complete guide.

What happens with no action at all

Leave the action out, and the browser falls back to submitting to the page's own URL. On a site with a server-side framework, that might do something. On a static site — plain HTML, a React build, Hugo, anything on GitHub Pages or S3 — there is nothing listening for POST requests. The server returns the page again (or an error), the browser reloads, and the visitor's message evaporates. No error message, no log entry, nothing.

This failure is invisible from your side, which is what makes it dangerous: the form looks fine, visitors believe they contacted you, and you believe nobody is writing in. If your form has been live for a while and you've received suspiciously little, test it right now — and check the rest of the contact form troubleshooting guide if the test doesn't arrive.

Storage vs email: the two destinations (and why you want both)

After the server receives a submission, it can do two useful things with it, and they fail in opposite ways:

• Email notification. Great as an alert — submissions come to you. Fragile as a record: notification emails get spam-filtered, bounced, deleted, and buried. If email is the only destination, a deliverability hiccup means a permanently lost lead. (Why those emails go to spam is its own saga: read the deliverability post.)
• Stored record — a database row, a dashboard entry, a spreadsheet line. Great as the source of truth: searchable, exportable, immune to spam filters. Weak as an alert: it only helps if you check it.

The reliable architecture is storage-first with email as the alert layer. This is how splitforms works by default: every submission is stored permanently in a dashboard (searchable, filterable, exportable to CSV), and a notification email goes out for each one — free for 500 submissions a month. If the email ever goes missing, the submission is still sitting in the dashboard, and you can re-deliver it to a webhook or forward it again. Email-only free tiers (Web3Forms being the best-known example) skip the storage layer entirely, which is fine for throwaway projects and risky for anything that earns money.

Where to find your submissions, platform by platform

"Where do form submissions go" has a different concrete answer on every major platform. Here's the field guide:

WordPress

It depends entirely on the form plugin. Contact Form 7 only emails submissions by default — if the email fails, the data is gone (the Flamingo add-on adds storage). WPForms and Gravity Forms store entries in your WordPress database; look for WPForms → Entries or Forms → Entries in wp-admin. If you'd rather skip plugins altogether, you can point a plain HTML form at an external backend — see adding a WordPress contact form without a plugin.

Wix

Wix form submissions land in the Wix Inbox (Dashboard → Inbox) and each submitter is also added to your Contacts list. You can enable email notifications per form in the form's settings. Submissions stay inside Wix — exporting means downloading contacts as CSV.

Squarespace

Form block submissions are emailed to the address you set in the block's storage settings, and stored under Contacts (look for the "Form Submitters" list). You can also connect a block to Google Sheets or Mailchimp as additional storage destinations.

Webflow

Native Webflow form submissions are stored in your project under Site settings → Forms, with email notifications to addresses you configure there. Note that Webflow caps monthly form submissions by plan — many Webflow sites outgrow this and point their forms at an external backend instead, which is just a matter of changing the form's action URL (walkthrough: contact forms on Webflow).

Netlify

If you add the netlify attribute to a form on a Netlify-hosted site, submissions appear in the Netlify dashboard under your site's Forms tab, with optional email notifications. Free tier covers 100 submissions per month per site — and the forms only work while the site is hosted on Netlify.

Google Forms

Responses live on Google's servers, viewable in the form editor's Responses tab, optionally synced to a Google Sheet. Nothing is emailed to you by default beyond an optional alert. (Whether you should embed a Google Form on your site at all is a separate question — we compare the trade-offs in Google Form embed vs native form.)

Hosted form backend (splitforms)

Submissions go to the backend's servers and appear in your dashboard the moment they arrive, with an email notification sent to you in parallel. Because the destination is an action URL rather than a platform feature, this answer is the same no matter where your site is hosted — and stays the same if you switch hosts later.

How to trace a missing submission in 3 steps

When a submission seems to have vanished, follow the journey backwards:

1. Check the stored copy first. Dashboard, Entries screen, Inbox, Responses tab — whatever your platform calls it. If it's there, the form works and your problem is email delivery (check spam, then check your notification address).
2. Submit a test yourself with the browser's dev tools open. Network tab → submit → look at the POST request. A 200 response means the server accepted it; 404 means your action URL is wrong; no request at all means JavaScript is intercepting the form and failing.
3. Confirm the form fields have name attributes. A form that submits successfully but arrives empty almost always has inputs missing their name — the data was never collected in the first place.

Ninety percent of missing-submission mysteries resolve at step 1: the data arrived fine and the notification email went to spam.

FAQ

Related reading: what is a form backend, do I need a backend for a contact form, receive form submissions by email, and the splitforms docs.