Guide Errors & Troubleshooting

How to fix a contact form that does nothing

Nothing happens when the button is clicked, and the failure could be sitting in the browser, the server, or the email step after both.

iFastHosting Support Team Updated 26 August 2026 7 min read Intermediate

Someone clicks Submit and nothing happens — no confirmation message, no error, no email arriving. This is one of the more frustrating faults to diagnose from the outside, precisely because there's usually no visible error to search for. A form submission actually passes through three separate stages, and the fault can be sitting in any one of them, so the fastest way in is to work out which stage it's failing at rather than guessing at a fix straight away.

The three stages, and how to tell them apart

The browser — JavaScript validates the fields and sends the data, either to the same page or to a separate handler.
The server — a script receives that data, checks it, and attempts to act on it, usually by sending an email.
Mail delivery — the message has to actually leave the server and land somewhere you'll see it.

A fault in stage one means the browser never even sends anything. A fault in stage two means the server receives the data but fails to process it. A fault in stage three means everything worked, right up until the message needed to actually arrive somewhere.

Checking stage one: is the browser actually sending anything?

Open developer tools (F12), switch to the Console tab, and submit the form. A JavaScript error here — commonly something referencing a missing script, an undefined function, or a blocked resource — stops the submission before it ever leaves the page, and it happens silently from the visitor's point of view.

Next, check the Network tab. Submit the form again and look for a request going out at the moment you click submit. If nothing appears in the Network tab at all, the fault is definitely in the browser layer — the button isn't wired up to actually do anything, usually because of the JavaScript error you just found, or a script that failed to load in the first place.

A common specific cause: a caching or minification plugin

Plugins that combine and minify JavaScript files can occasionally break a form script that depends on loading in a particular order relative to another script. If a form stopped working right after enabling or updating one of these, try excluding the form's page from that optimisation, or disabling it briefly to confirm.

Checking stage two: did the server receive it?

If the Network tab shows a request going out, click it and check the response. A 200 OK with no error means the server accepted the request; anything else — a 403, 404, or 500 — points at a server-side problem with the exact same causes as those errors elsewhere on a site: a permissions issue, a missing file, or a fault in the form-handling code itself.

A CORS error specifically — visible in the console, mentioning "Cross-Origin Request Blocked" — means the form is trying to submit to a different domain than the one serving the page, and the browser is refusing on security grounds. This is common with forms embedded from a third-party service, or after a domain change that wasn't updated everywhere. See our guide on fixing a CORS error if this is what you're seeing.

Checking stage three: mail delivery

If the server accepted the submission — a 200 response, and the form itself shows a "thank you" or success message — but no email ever arrives, the fault has moved from the form to mail delivery, which is a genuinely separate system. Check:

Spam and junk folders, on both the sending and receiving side if you have access to both.
The address the form is configured to send to — a typo here is easy to introduce and easy to miss, since the form still reports success either way.
Whether the form uses PHP's built-in mail function or SMTP. Many hosting environments deliver more reliably, and with far better logging, through SMTP than through PHP's default mail sending. Our guide on fixing email that isn't sending covers configuring this properly.

Testing the whole chain deliberately

Submit the form with developer tools open
Watch the Console for JavaScript errors and the Network tab for the outgoing request and its response.
Confirm the request actually reaches the server
A visible request with a successful response confirms stages one and two are both working.
Check spam folders before assuming delivery has failed
This resolves a surprising number of "it just doesn't send" reports on its own.
Send a test submission to a different email address
If it arrives at a second address but not the original one, the problem is specific to that inbox or address rather than the form itself.

If the form worked before and recently stopped

As with most sudden faults, ask what changed. A plugin update, a theme change, a new caching or minification setting, or a change to the mailbox the form sends to are the most common triggers. Testing the form immediately after any of these changes, before assuming it was working correctly, saves a lot of time later.

If you're still stuck

Note which stage the fault happens at — no outgoing request, a specific error response, or a success message with no email arriving — along with the exact page and time you tested it. That detail lets support check server logs and mail delivery records directly rather than needing to reproduce the fault from scratch.

Frequently asked questions

The form says it sent, but I never receive the email. What now?

Check your spam or junk folder first — form emails are a common false positive for spam filters. If it genuinely isn't arriving anywhere, the problem is most likely in mail delivery rather than the form itself. See our guide on fixing email that isn't arriving.