You hit submit. The button spins. Then... nothing. No success message, no error, no redirect. The form just sits there like you never touched it.
If you've ever Googled "form submit fails no error message" at 11pm because a customer emailed saying your contact form is broken, you already know the worst part: you can't reproduce it. It works fine on your machine. Every. Single. Time.
This guide breaks down why forms fail silently, the four most common root causes, and how to find the real culprit without guessing.
Why "no error" is the most expensive kind of error
A loud error is a gift. The user sees something is wrong. You see a stack trace. You fix it.
A silent failure is the opposite. The user thinks they submitted. You think the form works. The lead just... evaporates. Industry data puts contact form abandonment at 67-81% on average, and a meaningful slice of that is people who did try to submit and got nothing back.
The form didn't fail. The feedback failed. That's a different bug — and it's almost always one of four things.
The 4 reasons forms submit with no error
1. The JavaScript handler swallowed the error
This is the number-one cause in the wild. The submit handler wraps the request in a try/catch, the catch block calls a displayError() function, and that function only runs if the response includes a specific error field. When the server returns a 200 with a blank body, or a 500 with HTML instead of JSON, the catch block parses nothing and shows nothing.
You can spot this in the code if you wrote it. You can't spot it if you're a marketer staring at a Webflow form built by someone who left the company.
2. CORS blocked the request before it left the browser
The form looks like it submitted because event.preventDefault() ran. The fetch call fired. Then the browser quietly killed the request because the response didn't include the right Access-Control-Allow-Origin header.
The user sees nothing. The server logs show nothing — the request never arrived. The only place this shows up is the browser console, which 99% of users never open.
3. A validation rule failed silently
Custom inputs with setCustomValidity() and shadow DOM components frequently break the browser's default error reporting. The form's reportValidity() blocks the submit, but the custom input never surfaces a message. The form just refuses to go anywhere with no visible reason.
This is especially common in modern stacks using web components or React form libraries that hijack the submit event.
4. The endpoint is returning a redirect to a 404
Your form posts to /api/contact. Two months ago someone moved it to /api/v2/contact and added a redirect. The redirect works in Postman. In the browser, the fetch follows the redirect, lands on the new endpoint, and gets back HTML for a Next.js error page. The frontend tries to .json() the response, throws inside the catch, and the catch's own error handler doesn't know what to display.
User sees nothing. Server returns 200. Logs look fine.
The reason these bugs hide for months
Every fix above requires watching what actually happened in the user's browser. Your dev tools won't help you — you can't reproduce it. Your server logs won't help — half these bugs never reach the server. Asking the user "what did you see?" gives you "I clicked submit and nothing happened," which you already knew.
What you need is the network request, the response payload, and the DOM state at the moment of the click. Together. From the actual session that failed.
How to find the real cause in under 60 seconds
This is exactly what session replay was built for. When a user submits a form, CloseTrace records the click, the network request that fires, the response that comes back (status code, headers, body), and the DOM state before and after — all stitched into one playable timeline.
When someone reports the form is broken, you open their session, scrub to the submit click, and see:
- The button click event fired ✓
- The POST went to
/api/contact✓ - The response was a 302 redirect to
/api/v2/contact— and that returned 500 - The frontend's catch block tried to parse HTML as JSON and failed
You went from "we have no idea why this user couldn't submit" to "the v2 endpoint is throwing on Safari users with adblockers" in less than a minute. No guessing, no asking the user to repeat what they did.
If you're not sure whether replay is the right tool versus dedicated form analytics, the short answer is: form analytics tells you that a submit failed; replay tells you why.
What to do right now
If you're seeing reports of silent form failures, here's the order to work through:
- Open the browser console and submit the form yourself with network throttling on. Half the time you'll see the CORS or 404 error immediately.
- Check that your submit handler's catch block actually calls
displayErrorfor non-JSON responses, not just for parsed error fields. - Look at the response your endpoint sends on a real failure — make sure it returns JSON with a known error shape, not an HTML error page.
- If the failure is intermittent or browser-specific, you need replay. There's no other way to see what one specific user's browser did.
The takeaway: silent form failures aren't really form bugs. They're feedback bugs. Fix the feedback loop — server returns a parseable error, frontend always renders something — and the "no error message" reports stop. Until then, watching the actual session is the only shortcut that works.
Related reading: