DEV Community: Formgong

We sent a wrong key to 7 form backends. Three of them told the form it worked.

Formgong — Fri, 09 Oct 2026 14:09:01 +0000

Disclosure first: we build Formgong, one of the seven services below. That is why we wrote down the tests and the pass rules before sending a single request, and why every answer below is quoted as the service returned it.

A contact form on a static or AI-built site usually ends like this:

const response = await fetch(endpoint, { method: "POST", headers: { Accept: "application/json" }, body });
if (response.ok) showThankYou();

So the form is only as honest as the form backend's answer. If the backend replies 200 OK to a key that does not exist, the visitor sees "Thank you", the owner gets nothing, and nobody notices until a customer asks why they never got a reply. In an earlier test of 105 AI-built sites, 27 forms showed success and sent nothing.

We sent the same broken requests to seven form backends on 9 October 2026 to see which ones would catch the mistake.

The tests

Each service got made-up keys only, so nothing was delivered anywhere:

Placeholder key: the sample key from the service's own docs, the one tutorials and AI builders paste and people forget to replace.
Unknown key: a random key of the right shape.
Missing key: no key field at all (only for services where the key is a field, not part of the URL).
Browser JSON post: can a page on another site read the answer (CORS)?
Server post: the unknown key again, from a server instead of a browser.

Tests 1–4 ran in a normal Chrome 154 tab on https://example.com, with fetch, JSON and Accept: application/json. Test 5 ran with curl. The rule for tests 1–3 was simple: a wrong key must not get a 2xx status. For test 5, the answer had to be about the key, not a blanket refusal of server calls.

Results

Service	Placeholder key	Unknown key	Missing key	Browser (CORS)	Server post
Formspree	✅ 404	✅ 404	n/a	✅	✅ 404
Web3Forms	❌ 200, `success: true`	✅ 400	✅ 400	✅	❌ 403 for every server call
Forminit (formerly Getform)	❌ 200	❌ 200	n/a	✅	✅ (200, but about the form)
Basin	✅ 400	✅ 400	n/a	✅	✅ 400
FormSubmit	n/a*	❌ 200	n/a	✅	❌ 200, unrelated message
Formcarry	✅ 500	✅ 500	n/a	✅	✅ 500
Formgong	✅ 404	✅ 404	✅ 400	✅	✅ 404

* FormSubmit's placeholder is your@email.com, a real domain, and a first submission makes FormSubmit email that address. We did not send mail to a stranger.

Would your form show “Thank you” for a wrong key?

This is the part that matters for real code. Two common success checks, applied to what each service actually returned for a wrong key:

Service	`if (response.ok)`	`if (data.success)`
Formspree	No	No
Web3Forms, placeholder key	Yes	Yes
Web3Forms, unknown key	No	No
Forminit	Yes	No
Basin	No	No
FormSubmit	Yes	Yes
Formcarry	No	No
Formgong	No	No

With Web3Forms' sample key, FormSubmit with any wrong address, and Forminit with a status check, a misconfigured form looks like a working one.

What each service answered

Web3Forms: success for the sample key, and no server calls

With YOUR_ACCESS_KEY_HERE, the sample key from Web3Forms' installation docs, the answer was:

{"success": true, "message": "It works. Please insert your actual form_id or access_key to receive emails."}

HTTP 200 and success: true. The message asks you to insert a real key, but the code above never shows the message to anyone. A random key was handled well: 400 and "Invalid Form ID/Access Key! Please double check for extra space!".

From curl, the same request got 403: "This method is not allowed. Use our API in client side or contact support with server IP address (Pro plan is required)". Web3Forms' docs say so too: "Server side usage requires paid plan + server IP whitelisting". If your form posts through a Next.js route, a Server Action or a Supabase Edge Function, it does not work on the free plan.

Forminit (formerly Getform): 200 and “This form has been deleted”

Getform.io now redirects to Forminit. For both the placeholder and a random form ID, Forminit answered HTTP 200 with:

{"success": false, "error": "FORM_NOT_FOUND", "code": 404, "message": "This form has been deleted and is no longer available. Please contact support if you believe this is an error."}

The body is honest (success: false, FORM_NOT_FOUND), but the HTTP status is 200, so response.ok is true. And the message says the form was deleted, for an ID that never existed, which sends you to support instead of to your typo.

FormSubmit: 200, and `"success": "false"` as a string

For a random form address, FormSubmit answered HTTP 200 with:

{"success": "false", "message": "Email address 5f208483772f23807fae5d4f589e6af4 is not formatted correctly."}

"false" in quotes is a non-empty string, and a non-empty string is truthy in JavaScript, so if (data.success) passes. From curl, the answer was a different 200: "Make sure you open this page through a web server, FormSubmit will not work in pages browsed as HTML files." That message is about local HTML files, not about the request we sent.

Formcarry: right message, wrong status class

Formcarry rejected every wrong ID, which is what counts, with "Form is invalid… Make sure you are using the correct form ID". The status was 500 though, and the body said "code": 401. A 500 tells monitoring tools and retry logic that Formcarry's server broke, when the mistake was in the request.

Formspree and Basin: honest

Formspree answered 404 Form not found everywhere, including from a server. Basin answered 400 with a clear explanation everywhere. Neither will make a broken form look like a working one.

Formgong

404 with "code": "unknown_access_key" for the placeholder and for a random key, 400 with "code": "missing_access_key" when the key was missing, the same answers from a server, and the message in the visitor's browser language (our test tab was set to Ukrainian, so that is what came back).

Free plans, prices and where data lives

Taken from each service's own pricing and privacy pages on 9 October 2026:

Service	Free submissions / month	Cheapest paid plan	Data stored
Formgong	300	$9 / month ($86 billed yearly)	EU
Web3Forms	250	priced by location (we were shown Turkish lira)	US
Forminit	100 (1 form)	$19 / month	EU (AWS)
Formspree	50	$15 / month ($10 billed yearly)	US
Basin	50 (1 form)	$15 / month ($12.50 billed yearly)	Canada, with files in the US
Formcarry	50 (1 form)	$6 / month ($5 billed yearly)	EU
FormSubmit	"unlimited"	not stated	not stated

What to take from this

Whatever you use, test the wrong key once. Put a wrong key in your form, submit, and check that the page shows an error. It takes a minute and it catches the most common way a form silently stops working.
Check both the status and the body, and compare success with === true, not truthiness:

const data = await response.json().catch(() => ({}));
if (response.ok && data.success === true) showThankYou();
else showError(data.message || `Error ${response.status}`);

If you post from a server, rule out services that block server calls on the free plan.

Among the seven, Formspree, Basin and Formgong never let a wrong key look like success. Of those three, Formgong has the largest free plan (300 submissions a month against 50), the lowest paid price ($9 against $15) and keeps data in the EU. You can try it with the same wrong-key test above.

How we tested

One Chrome 154 tab on https://example.com sent tests 1–4 with fetch, six seconds apart to stay under per-IP limits. curl 8.7.1 sent test 5. Each service got its own random key per run; nothing was delivered. An earlier run from an automated (Playwright) Chrome got a Cloudflare bot challenge from Web3Forms instead of its API, so we discarded that run's Web3Forms row and re-ran every service from a normal browser; the other six services gave the same status codes and errors in both runs. The pass rules were fixed before the first request and not changed after.

Nodemailer + Gmail errors, reproduced: 535-5.7.8, “Missing credentials for PLAIN”, wrong version number, and serverless ports

Formgong — Fri, 09 Oct 2026 12:49:39 +0000

A contact form that sends through Gmail with Nodemailer usually fails in one of a handful of ways, and the error text often points in the wrong direction. We reproduced each failure against the real smtp.gmail.com on 9 October 2026, with Nodemailer 10.0.16 on Node and a made-up Gmail address, so every attempt failed before a message could be accepted. Then we ran the same code on Cloudflare Workers.

What we learned in short:

Missing credentials for "PLAIN" never reached Google. Nodemailer raises it itself when the password is empty, which almost always means an environment variable is not set where the code runs.
Gmail gives the same 535 for a wrong password and for an account that does not exist. The error cannot tell you which one you have.
secure must match the port. The wrong combination fails either instantly with an OpenSSL message or after a long silent wait.
On Cloudflare Workers none of Gmail's ports worked, even though the same code reached Gmail from wrangler dev on a laptop.

Every error at a glance

Setup	`err.code`	`err.command`	Message	Time to fail
Wrong password (port 465 or 587, or `service: "gmail"`)	`EAUTH`	`AUTH PLAIN`	`Invalid login: 535-5.7.8 Username and Password not accepted. For more information, go to 535 5.7.8 https://support.google.com/mail/?p=BadCredentials …`	0.4–0.6 s
Password empty or `undefined`	`EAUTH`	`API`	`Missing credentials for "PLAIN"`	0.4 s
No `auth` at all	`EENVELOPE`	`MAIL FROM`	`Mail command failed: 530-5.7.0 Authentication Required. …`	0.6 s
`secure: true` on port 587	`ESOCKET`	`CONN`	`…SSL routines:tls_validate_record_header:wrong version number…`	0.1 s
`secure: false` on port 465	`ETIMEDOUT`	`CONN`	`Greeting never received`	as long as `greetingTimeout`
Host typo `smtp.gmial.com`	`ESOCKET`	`CONN`	`connect ECONNREFUSED 51.79.68.169:465`	1.3 s
Normal password on an account with 2-Step Verification	`EAUTH`	`AUTH PLAIN`	`534-5.7.9 Application-specific password required` (from user reports; we could not reproduce it without a real account)

Log err.code, err.command and err.responseCode next to the message. Together they say which step failed: API means Nodemailer stopped before talking to anyone, CONN means the connection or TLS failed, AUTH PLAIN means Google rejected the login, and MAIL FROM means Google rejected the message itself.

535-5.7.8 “Username and Password not accepted”

This is the one everybody hits. We got it on port 465 with secure: true, on port 587 with secure: false, and with the service: "gmail" shortcut. All three are correct transport settings, and all three reached the login step.

Two things worth knowing:

It does not tell you whether the account exists. Our address was made up and Gmail still said "Username and Password not accepted", exactly as it does for a real account with a wrong password. So check the user value too: it must be the full address, such as you@gmail.com, and must be the same account the app password was created in.
Your normal Google password is the wrong password. Gmail no longer accepts the account password from apps like Nodemailer. You need an app password:
- Turn on 2-Step Verification for the account.
- Create an app password at myaccount.google.com/apppasswords.
- Put the 16 characters it shows into auth.pass.

Google's help page says app passwords work only with 2-Step Verification on. It also lists three cases where the option is missing: 2-Step Verification set up only with security keys, a work or school account, or Advanced Protection. In those cases use OAuth2 (Nodemailer supports it) or a sending service instead.

If the app password still fails, check how it reached your code. Google shows it in groups of four with spaces; paste it without them to rule that out. A stray quote or a trailing newline in a .env file breaks it too. (We could not test which of these Gmail tolerates: with a made-up account every login fails the same way.)

“Missing credentials for "PLAIN"”: Gmail was never asked

Error: Missing credentials for "PLAIN"
  code: 'EAUTH', command: 'API'

command: 'API' is the giveaway: Nodemailer threw this before it sent anything to Google. We got it by passing pass: undefined, which is what process.env.GMAIL_APP_PASSWORD is when the variable does not exist in that environment.

Typical reasons:

The variable is in your local .env, but not in the hosting dashboard (Vercel, Netlify, Supabase secrets).
It is set for Preview but not for Production, or the other way round.
It was added after the last deploy, and the running deployment does not have it yet. Redeploy.
The code that sends mail runs in the browser, where server variables do not exist. Sending mail must happen on the server: anything in browser code, including an app password, is visible to every visitor.

530-5.7.0 “Authentication Required”

Leave out auth entirely and Gmail lets you connect, then refuses the message at MAIL FROM with 530-5.7.0 Authentication Required. The error code is EENVELOPE, which sounds like a problem with your addresses, but it is the same missing login. Usually auth was spread from an object that turned out empty.

`secure` and port: two very different failures

Gmail listens on 465 for TLS from the first byte and on 587 for plain text upgraded with STARTTLS. Nodemailer's secure: true means the first; secure: false means the second.

secure: true on 587 fails at once with an OpenSSL error: SSL routines:tls_validate_record_header:wrong version number. Nothing in it says "port", which is why this one sends people searching for OpenSSL bugs.
secure: false on 465 fails slowly. The server waits for a TLS handshake, the client waits for a plain-text greeting, and nobody speaks. We set greetingTimeout to 10 seconds and got Greeting never received after 10.06 seconds. With Nodemailer's default timeouts the wait is longer, which on a serverless platform can mean the function hits its own time limit first and you see a platform timeout instead of an SMTP error.

The two working combinations:

// Either: TLS from the start
{ host: "smtp.gmail.com", port: 465, secure: true, auth: { user, pass } }
// Or: STARTTLS
{ host: "smtp.gmail.com", port: 587, secure: false, auth: { user, pass } }

A typo in the host goes to someone else's server

We tried smtp.gmial.com. It resolved, to an address at the hosting company OVH, not to Google, and the connection was refused on ports 25, 465 and 587. So today you get ECONNREFUSED. But a typo domain that resolves can start accepting connections at any time, and then your Gmail address and app password go to whoever runs it. If you see ECONNREFUSED with an IP address you do not recognise, check the spelling of host before anything else, and rotate the app password if a typo was ever deployed.

Serverless: it works locally, then fails after deploy

Cloudflare Workers

We deployed a Worker (with nodejs_compat) that tries the same Gmail login on each port, and called it twice. Both runs gave the same answers:

Port	Result on Cloudflare Workers
465	`ESOCKET`: `proxy request failed, cannot connect to the specified address`
587	`ESOCKET`: `TLS Handshake Failed.`
25	`ESOCKET`: `Connections to port 25 are prohibited`

None of them reached the login step. The same Worker run locally with wrangler dev behaved differently: port 587 and port 25 reached Gmail and got the normal 535. So a Worker can pass every local test and still fail on every port once deployed.

Supabase Edge Functions (Lovable, Bolt)

Supabase's limits page says: "Outgoing connections to ports 25 and 587 are not allowed." That leaves 465 for Gmail. We did not run Nodemailer in an Edge Function for this article, so treat this as the documented rule rather than a tested result.

Vercel and Netlify functions

We did not test these. If you see a function timeout with no SMTP error, check the secure and port pair above first, because the slow failure is long enough to hit a function limit.

A transport that tells you what went wrong

import nodemailer from "nodemailer";

const user = process.env.GMAIL_USER;
const pass = process.env.GMAIL_APP_PASSWORD;
if (!user || !pass) {
  // Fail with a clear message instead of Nodemailer's 'Missing credentials for "PLAIN"'.
  throw new Error("GMAIL_USER or GMAIL_APP_PASSWORD is not set in this environment");
}

const transporter = nodemailer.createTransport({
  host: "smtp.gmail.com",
  port: 465,
  secure: true, // must be true for 465 and false for 587
  auth: { user, pass },
  connectionTimeout: 10_000,
  greetingTimeout: 10_000, // fail fast instead of hitting the platform's time limit
});

export async function sendContactMessage({ name, email, message }) {
  try {
    await transporter.sendMail({
      from: user, // Gmail sends from the account you logged in with
      replyTo: email, // so Reply goes to the visitor
      to: user,
      subject: `New message from ${name}`,
      text: message,
    });
  } catch (err) {
    // These three fields identify the failing step; the message alone often misleads.
    console.error("mail failed", { code: err.code, command: err.command, responseCode: err.responseCode, message: err.message });
    throw err;
  }
}

Checklist

command: 'API' with "Missing credentials": the password variable is not set where the code runs.
535-5.7.8: use an app password, not your Google password, and the full address as user.
534-5.7.9: same fix; the account has 2-Step Verification and you sent the normal password.
"wrong version number": you set secure: true on port 587.
"Greeting never received" or a function timeout: you set secure: false on port 465.
ECONNREFUSED to an unfamiliar IP: check the spelling of host.
Works locally, fails deployed on Cloudflare Workers or Supabase: the platform blocks the port. Use an HTTP email API or a form backend instead of SMTP.

How we tested

Node with Nodemailer 10.0.16, one connection per case to smtp.gmail.com, a made-up address (formgong.repro.nobody.4417@gmail.com) and made-up passwords, so Gmail rejected every attempt and nothing was sent. The Cloudflare Workers results come from a Worker deployed for the test and removed afterwards; each port was tried twice. Google's app password rules are quoted from Google's help page, the Supabase rule from Supabase's Edge Function limits, and the 534-5.7.9 text from user reports such as WP Mail SMTP's write-up.

We build Formgong, a form backend: your form posts to it over HTTPS and it sends the notification, so there is no SMTP login, app password or blocked port to deal with. If your form fails in the browser before it ever reaches the server, our “Failed to fetch” write-up covers that side.

“Failed to fetch” in a contact form: 10 causes, reproduced in Chrome, Firefox and Safari

Formgong — Fri, 09 Oct 2026 12:28:24 +0000

Your contact form calls fetch(), and the catch block gets TypeError: Failed to fetch. Most guides then list possible causes and stop there. We wanted to know what each cause looks like in practice, so we built a small test bench: one page, one API on another port, and a case for every common reason a form submission fails. We ran each case in Chrome 154, Firefox 155 and WebKit 26.6 (the engine behind Safari) on 9 October 2026. Firefox and WebKit were the Playwright builds of those engines.

Three findings changed how we debug these errors:

The error message tells you nothing. Every cause produced the same text in a given browser: Failed to fetch in Chrome, NetworkError when attempting to fetch resource. in Firefox, Load failed in Safari. The cause is only visible in the console or the Network tab.
A CORS error does not mean the message was lost. In one case the server received the form, processed it and answered 200, and the page still showed an error.
A dropped connection can send the form more than once. When the server closed the connection without answering, Chrome sent the POST twice and Firefox sent it ten times.

What the error says in each browser

The catch block received the same thing for all of the network causes below:

Browser	`error.name`	`error.message`
Chrome	`TypeError`	`Failed to fetch`
Firefox	`TypeError`	`NetworkError when attempting to fetch resource.`
Safari (WebKit)	`TypeError`	`Load failed`

So code like if (err.message === "Failed to fetch") only works in Chrome. If you want to tell users "check your connection", test err instanceof TypeError instead.

The console tells the causes apart

This is what each browser printed to the console. "Reached the server" is what our API logged.

Cause	Reached the server?	Chrome console	Firefox console	Safari console
No CORS headers, JSON body (preflight)	Only the `OPTIONS` preflight	`…has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header…`	`Cross-Origin Request Blocked… (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 204.`	`Origin … is not allowed by Access-Control-Allow-Origin. Status code: 204`
No CORS headers, `FormData` body (no preflight)	Yes, the POST arrived and got 200	`…has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present…`	`…(Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.`	`…not allowed by Access-Control-Allow-Origin. Status code: 200`
Preflight rejected with 401	Only the preflight	Same as the first row; the 401 is not mentioned	`…CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 401.`	`Preflight response is not successful. Status code: 401`
Server not running (connection refused)	No	`net::ERR_CONNECTION_REFUSED`	`Cross-Origin Request Blocked… (Reason: CORS request did not succeed). Status code: (null).`	`Could not connect to the server.`
Domain does not resolve	No	`net::ERR_NAME_NOT_RESOLVED`	Same CORS-looking message as above	`A server with the specified hostname could not be found.`
Server drops the connection	Yes (see below)	`net::ERR_EMPTY_RESPONSE`	Same CORS-looking message	`The network connection was lost.`
Page's Content Security Policy blocks the API	No	`Refused to connect because it violates the document's Content Security Policy.`	`Content-Security-Policy: The page’s settings blocked the loading of a resource (connect-src)…`	`Refused to connect to … because it does not appear in the connect-src directive…`
HTTPS page posting to an `http://` endpoint	No	`Mixed Content: The page at '…' was loaded over HTTPS, but requested an insecure resource '…'. This request has been blocked…`	Nothing reached our console log	`[blocked] The page at … requested insecure content from …`

Things to notice:

Firefox reports a dead server as a CORS problem. With the API stopped, or a domain that does not exist, Firefox printed "Cross-Origin Request Blocked … CORS request did not succeed". People then spend an hour adding CORS headers to a server that is not running. Check the status code in that message: (null) means no response arrived at all, so this is not a CORS header problem.
Chrome hides the preflight status. When the preflight got a 401, Chrome said only that the CORS header was missing. Safari printed the 401 itself. If Chrome says "preflight… doesn't pass", open the Network tab and look at the OPTIONS request's status.
Mixed content is easy to miss. Our test captured no console line from Firefox for it at all, only the generic error. If the page is HTTPS, check that the form's endpoint URL starts with https://.

The CORS error that still delivered the message

A fetch with a FormData body and no custom headers is a "simple" request (so is a URLSearchParams body, per the Fetch standard; we tested FormData): the browser sends it straight away, without asking the server first. In our test the POST reached the server, the server handled it and answered 200, and only then did the browser refuse to show the response to the page, because there was no Access-Control-Allow-Origin header.

For a contact form that means: the email was sent, and the visitor saw an error. Many of them will press Send again. If your inbox has duplicate messages from the same person a few seconds apart, this is the first thing to check.

A JSON body (Content-Type: application/json) is different: the browser sends an OPTIONS preflight first, the preflight fails, and the POST is never sent.

The fix is the same in both cases: the endpoint must answer with Access-Control-Allow-Origin (your site's origin, or * for a public form endpoint), and for JSON it must also answer the OPTIONS request with Access-Control-Allow-Headers: Content-Type.

A dropped connection sends the form again

We made the server close the connection as soon as the request arrived, without any response. This is what happens when a serverless function crashes mid-request or a proxy kills it. Then we counted the POST requests that reached the server for a single fetch() call, three times per browser:

Browser	POSTs received per `fetch()`
Chrome	2, 2, 2
Firefox	10, 10, 10
Safari (WebKit)	1, 1, 1

The browser retries on its own before your code sees the error. If your server did the work (sent the email, saved the row) and then crashed before answering, Firefox can deliver the same message up to ten times. Two defences:

Make the handler respond before slow side effects, or make them idempotent: put a random id in the request (generated once per form fill) and ignore an id you have already seen.
Do not add your own automatic retry on TypeError without such an id.

Submit button without `preventDefault()`

A classic: the form's submit handler calls fetch() but never calls event.preventDefault(), so the browser also submits the form the normal way and reloads the page. The three browsers disagreed completely:

Browser	Did the POST reach the API?	Did the code see an error?
Chrome	Yes	No. The page navigated away and the promise never settled.
Firefox	No	Yes, `NetworkError when attempting to fetch resource.`
Safari (WebKit)	Yes	Yes, `Load failed`

So the same bug looks like "it works but the page reloads" in Chrome, "it never sends" in Firefox, and "it sends but shows an error" in Safari. If your form behaves differently in each browser, look for a missing preventDefault() first. A reload with your field values appearing in the address bar (?email=…) is the giveaway.

Not causes of "Failed to fetch"

Two things are often blamed but behave differently:

A 500 (or 404, or 429) from the server does not throw. fetch resolves with response.ok === false. If you only catch errors, a failing server looks like success. Always check response.ok.
A timeout has a different name in each browser. With AbortSignal.timeout(1500) we got TimeoutError: signal timed out in Chrome, TimeoutError: The operation timed out. in Firefox, and AbortError: Fetch is aborted in Safari. Code that checks err.name === "TimeoutError" misses Safari; check for both names.

A submit handler that survives all of the above

const form = document.querySelector("#contact");
const button = form.querySelector("button[type=submit]");
const status = form.querySelector(".status");
// One id per form fill, so a retried or repeated request can be recognised on the server.
// crypto.randomUUID() works on HTTPS pages and localhost only.
let submissionId = crypto.randomUUID();

form.addEventListener("submit", async (event) => {
  event.preventDefault(); // without this, each browser fails in its own way
  button.disabled = true; // stops double clicks while the request is in flight
  status.textContent = "Sending…";
  const data = new FormData(form);
  data.set("submission_id", submissionId);
  try {
    const response = await fetch(form.action, {
      method: "POST",
      headers: { Accept: "application/json" },
      body: data,
      signal: AbortSignal.timeout(15000),
    });
    const result = await response.json().catch(() => ({}));
    if (!response.ok || result.success === false) {
      // The server answered: show its message, not a generic network error.
      status.textContent = result.message || `The server answered ${response.status}. Please try again.`;
      return;
    }
    status.textContent = "Thank you, your message was sent.";
    form.reset();
    submissionId = crypto.randomUUID();
  } catch (err) {
    const timedOut = err.name === "TimeoutError" || err.name === "AbortError";
    status.textContent = timedOut
      ? "The server took too long to answer. Your message may still have arrived, so check before sending again."
      : "Could not reach the server. Check your connection and try again.";
  } finally {
    button.disabled = false;
  }
});

The timeout message is careful on purpose: as the tests above show, a request that times out on the client may still have been delivered.

Checklist when you see the error

Open DevTools, then the Network tab, and submit again. Is there an OPTIONS request? A red POST? No request at all?
Read the console line next to it, not the catch message. Use the table above to match it to a cause.
In Firefox, a "CORS request did not succeed" with Status code: (null) means the server never answered: check the URL and whether the server is up.
Check the endpoint URL starts with https:// on an HTTPS page.
Check the site's Content-Security-Policy header allows the endpoint in connect-src.
Check the endpoint's own logs: the message may have arrived even though the page showed an error.
Make sure the submit handler calls event.preventDefault().

How we tested

A local Node server played the API on one port and the page on another, so every request was cross-origin, like a static site posting to a form service. Each case ran in a fresh tab in Chrome 154.0.8037.99 (stable channel), and in Playwright's Firefox 155.0 and WebKit 26.6 builds, driven by Playwright 1.63. Nothing was sent anywhere except one DNS lookup for a .invalid domain, which never resolves. Browser extensions (ad blockers that block form endpoints) were not tested, because we could not reproduce them reliably in an automated browser.

We build Formgong, a form backend for static and AI-built sites. Its endpoint answers preflights and sends CORS headers for any origin, and it answers {"success": false, "message": …} with a real status code instead of failing silently. If you are debugging a specific service, we also wrote up the exact error messages of EmailJS, Resend, Formspree and Web3Forms.

DEV Community: Formgong

We sent a wrong key to 7 form backends. Three of them told the form it worked.

The tests

Results

Would your form show “Thank you” for a wrong key?

What each service answered

Web3Forms: success for the sample key, and no server calls

Forminit (formerly Getform): 200 and “This form has been deleted”

FormSubmit: 200, and "success": "false" as a string

Formcarry: right message, wrong status class

Formspree and Basin: honest

Formgong

Free plans, prices and where data lives

What to take from this

How we tested

Nodemailer + Gmail errors, reproduced: 535-5.7.8, “Missing credentials for PLAIN”, wrong version number, and serverless ports

Every error at a glance

535-5.7.8 “Username and Password not accepted”

“Missing credentials for "PLAIN"”: Gmail was never asked

530-5.7.0 “Authentication Required”

secure and port: two very different failures

A typo in the host goes to someone else's server

Serverless: it works locally, then fails after deploy

Cloudflare Workers

Supabase Edge Functions (Lovable, Bolt)

Vercel and Netlify functions

A transport that tells you what went wrong

Checklist

How we tested

“Failed to fetch” in a contact form: 10 causes, reproduced in Chrome, Firefox and Safari

What the error says in each browser

The console tells the causes apart

The CORS error that still delivered the message

A dropped connection sends the form again

Submit button without preventDefault()

Not causes of "Failed to fetch"

A submit handler that survives all of the above

Checklist when you see the error

How we tested

FormSubmit: 200, and `"success": "false"` as a string

`secure` and port: two very different failures

Submit button without `preventDefault()`