# Why Is My Contact Form Not Working? Find the Fix Fast

A debugging checklist for broken contact forms. Find out why nothing submits, why submissions arrive empty, or why the email never shows up, with fixes.

Nine times out of ten, a broken contact form is **one of five problems**: the button never actually submits, the fields have no `name` attributes, the action URL can't receive anything, the request gets blocked with a 405 or CORS error, or the form works fine and it's the email notification that's broken.

This is the checklist I use to figure out which one it is. Quickest checks first.

If you'd rather skip the manual work: paste your form's HTML into our [free contact form checker](/tools/contact-form-checker) and it names most of these defects automatically, then hands you a fixed version. The rest of this post is for understanding what actually went wrong, and for the failures no static checker can see.

## Start with the Network tab

Before touching any code, **open your browser's DevTools (F12), switch to the Network tab, and click submit once**. What you see there tells you which section to jump to. This works even on WordPress or Squarespace where the markup isn't yours: the request doesn't care who wrote the form.

| What you see | The problem | Go to |
| --- | --- | --- |
| No request at all | The form never submits | [Nothing happens](#nothing-happens-when-you-click-submit) |
| A request with an empty payload | Missing `name` attributes | [Submissions arrive empty](#the-page-reloads-and-the-submission-arrives-empty) |
| Your email app opens | A `mailto:` action | [The action can't receive anything](#the-action-url-cant-receive-anything) |
| A red request: 404, 405, CORS | The endpoint rejects it | [The request is blocked](#the-request-is-blocked-404-405-or-cors) |
| A green 200, but no email | Delivery is the problem | [The email never arrives](#the-form-works-and-the-email-is-whats-broken) |

![Moss from The IT Crowd calmly typing while a fire burns next to him](https://media.giphy.com/media/13HgwGsXF0aiGY/giphy.webp)

*That's the map. Now the fixes.*

## Nothing happens when you click submit

No request in the Network tab means the browser never tried. Four causes cover almost every case.

**The button opts out of submitting.** A `<button>` inside a form submits by default, but `type="button"` switches that off. It's a common leftover from component libraries:

```html
<!-- This button will never submit the form -->
<button type="button">Send</button>

<!-- This one will -->
<button type="submit">Send</button>
```

**The button isn't inside the form.** If your markup closes `</form>` before the button (easy to do with nested divs), clicking it does nothing. Move it inside, or wire it up explicitly with the `form` attribute: `<button form="contact-form">`.

**JavaScript crashed before the request.** If a script intercepts the submit, one error kills the whole flow. Check the Console tab. An error like this one means your script ran before the form existed in the DOM:

```text
Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
```

Move the script below the form, or wrap it in a `DOMContentLoaded` listener. And while you're in there: if your handler calls `event.preventDefault()` and the `fetch` after it fails, the form does nothing at all. Native submission is the more reliable default unless you need inline behavior.

**A hidden required field is blocking validation.** If a `required` field is hidden with CSS (a collapsed accordion step, a display-none wrapper left over from a redesign), the browser refuses to submit and can't show the validation bubble either. Nothing visibly happens, but the console gives it away:

```text
An invalid form control with name='phone' is not focusable.
```

Either remove `required` from fields you hide or remove the hidden field entirely.

## The page reloads and the submission arrives empty

This one is sneaky because everything looks like it works. The page navigates, maybe you even see a thank-you screen, and then the submission shows up with no data in it. Or the request payload in the Network tab is just empty.

The cause is almost always missing `name` attributes. Browsers build the payload exclusively from fields that have a [`name`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input#name). Not `id`, not `placeholder`. **No name, no data:**

```html
<!-- Submits absolutely nothing -->
<input type="email" id="email" placeholder="Your email">

<!-- Submits email=... -->
<input type="email" id="email" name="email" placeholder="Your email">
```

I've seen forms run in production for weeks like this. Every submission arrived, every submission was blank, and nobody noticed because the thank-you page kept loading fine.

Two related gotchas while you're checking names: when two non-checkbox fields share one `name`, the browser sends both values and most backends keep only one. And if the form has no `method="post"`, it submits with GET and your field values end up in the URL, where they get logged, truncated, and cached.

## The action URL can't receive anything

The `action` attribute is where the browser sends the data. A surprising number of broken forms point it somewhere that was never going to work.

**`action="mailto:you@site.com"`** doesn't submit anything. It opens the visitor's email app with the data mangled into a draft, if it opens anything at all; on machines with no mail client configured, it silently does nothing. It also exposes your address to every scraper that reads your HTML.

**`action="http://localhost:3000/api/contact"`** works exactly once: on your machine.

![The "this is fine" dog sitting in a burning room](https://media.giphy.com/media/NTur7XlVDUdqM/giphy.webp)

**A relative path like `action="/api/contact"`** needs a server route answering at that path on your domain. If you deploy to a static host like GitHub Pages or Netlify without a function behind that route, the POST returns a 404 or 405.

The fix for all three is the same: point the action at a real endpoint that accepts form posts. That's your own server route if you have one, or a hosted form backend if you don't. With [Form Plume](/docs/quickstart) that's one URL:

```html
<form action="https://api.formplume.com/f/your-form-id" method="post">
```

If you're building the form from scratch anyway, the [HTML form generator](/tools/html-form-generator) outputs markup with all of this already correct.

## The request is blocked: 404, 405, or CORS

A red request in the Network tab means the browser sent the data and the other end refused it.

**404** means nothing answers at that URL. Check the action for typos, and on static hosts remember there is no server unless you deployed one.

**405 Method Not Allowed** is the static-host special: the file at that path exists, but the host only serves GET requests for it. You POSTed to a page, not an endpoint.

**CORS errors** only happen when JavaScript submits the form with `fetch`. The message looks like this:

```text
Access to fetch at 'https://api.example.com/submit' from origin
'https://mysite.com' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.
```

Native form submission (a plain `action` + `method="post"`) is **not subject to CORS at all**, which is one good reason to prefer it. If you need `fetch` for inline success states, the endpoint has to send CORS headers. Your own server route needs to set them; form backends built for browser submission do it out of the box.

## The form works and the email is what's broken

If the request returns 200, **stop debugging the form**. It's done, it delivered. The failure is somewhere in what happens next, and this is the most common "broken form" report of all: the form was never broken.

Check these in order:

1. **Where do submissions actually go?** If your backend has a dashboard or a stored submissions list, look there first. Data present means the form and endpoint both work.
2. **The spam folder.** Notification emails about "someone filled in a form" trip spam filters constantly, especially when the sender is your own domain without proper DNS records.
3. **The notification address.** Typos in the configured recipient are more common than anyone admits.
4. **Sending limits.** If notifications come from your own SMTP or a free email tier, you may have quietly run out.

If you built the email sending yourself with PHP `mail()` or a raw SMTP call, deliverability is now your full-time hobby. SPF, DKIM, DMARC, sender reputation, the lot. This is the part I'd genuinely outsource: a [form backend](/features) stores every submission independently of email, so a delivery hiccup never loses the lead.

## One more: file uploads arrive empty

If your form has a file input and the files come through as just a filename with no content, the form is missing [`enctype="multipart/form-data"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/form#enctype). Without it the browser submits the file's name and throws away the bytes. It needs `method="post"` too:

```html
<form action="..." method="post" enctype="multipart/form-data">
```

## The two-minute version

Everything above that lives in the markup, a static check can catch. Paste your form into the [contact form checker](/tools/contact-form-checker) and it grades the form, names each defect, and produces a corrected version with names, labels, and a honeypot added. Then **send one real submission from the deployed site** to prove the endpoint and the delivery, because those two things no static checker can see.

That last step matters. The checklist for staying out of this post in the future is short:

- After every deploy that touches the form, submit it once from the production URL.
- Keep a [honeypot field](/tools/form-spam-checker) in place so spam doesn't bury the real submissions you're testing for.
- Don't build email delivery yourself unless you want to own SPF and DKIM forever.