DEV Community: Formgong

What happens to a form submission after the free limit runs out

Formgong — Thu, 29 Oct 2026 17:24:50 +0000

Say your contact form has been fine for months. Then someone's bot finds it, or you have one good week, and the free plan runs out halfway through the month. The next customer who fills in the form might still get your "Thank you" page, and you might never get their message. Nothing on your side looks broken, so there's no reason to go and check.

On pricing pages, free form backends look almost the same: 50 a month here, 250 there. The part that differs is what happens to the message that arrives after that, and most vendors answer it in one FAQ line, if at all.

We're Formgong and we make one of the 14 services in this list, so treat our row with the suspicion you'd give any vendor writing about competitors. On 16 October 2026 we read every vendor's own pricing, docs and help pages for a bigger comparison, and on 29 October we fetched the same pages again with curl to see what had moved. We didn't run real accounts past the limit, so this is what each vendor says it does, quoted where the wording matters. There are no prices here; those change more often than anything else on these pages.

Service	Free limit	A submission over the limit
Formspree	50 a month	Saved to an Over Limit folder without notification emails; you reprocess it once you have room
Formcarry	50 a month, spam counts	Held until the 1st of next month (up to 1,900) while the visitor sees the normal thank-you page; past that the endpoint answers 401
Formspark	250 in total, not per month	A small buffer is held under Overflow and released when you buy a bundle; past that, discarded. JSON callers get 402
Formgong	1,000 a month	Still delivered on credit, up to 5,000 extra, until the 7th of next month; if unpaid, stored but not delivered until you pay, then 429
Forminit	100 a month	The form pauses; submissions are rejected, not stored and cannot be recovered
Static Forms	250 every 30 days	Rejected with an error, neither delivered nor stored; warning emails at 80% and 90%
Splitforms	500 in total, not per month	HTTP 429, not stored
FormKeep	50 a month per form, spam counts	Ignored and lost
Netlify Forms	Unlimited on credit-based plans	If the project goes over its plan limits, the whole project is paused
Jotform	100 a month	Forms are disabled and show "This Form Has Exceeded Its Allocated Quota"
Basin	50 a month	Its own pages disagree
FormBackend	50 a month	"Not dropped without warning"; held or rejected is not stated
Web3Forms	250 a month	Not stated in the docs; the pricing page refused our reader (403)
FormSubmit	No published limit	Nothing published to go over; the site was down when we checked on 29 October

Four of them throw the message away

Forminit, Static Forms, Splitforms and FormKeep don't keep anything that comes in over the limit. Forminit says it most plainly: submissions sent while a form is paused "are not stored or queued and cannot be recovered". Static Forms and Splitforms say much the same and send back an error status (Splitforms uses 429). FormKeep's pricing page says extra submissions are ignored, and an article on its support site says they will be lost.

There's one more thing about FormKeep, and Formcarry too. Both count spam toward the free 50. A bot that finds your form on the 3rd can spend the whole month for you.

Of all the bad outcomes, an error status is the one you can do something about, because your page sees it. If your form posts with fetch, look at the status and give the person another way to reach you:

const res = await fetch(endpoint, {
  method: "POST",
  headers: { Accept: "application/json" },
  body: new FormData(form),
});

if (res.ok) {
  showThanks();
} else {
  // 429 from Splitforms, 402 from Formspark, 401 from Formcarry past its hold
  showError("This didn't go through. Please email us at hello@example.com.");
}

With a plain HTML form and no JavaScript, the visitor lands on whatever error page the backend renders, and you have no say in what it says.

The ones that keep it

Formspree, Formcarry and Formspark hold on to over-limit submissions, so nothing disappears right away. Where they keep it is the problem. Formspree puts it in an Over Limit folder "without sending notification emails or running plugins". In fairness, Formspree also emails you when that starts and warns you at 50%, 75% and 90%, which is more than most do. Formcarry sets the extra submissions aside until the first day of the next month, and meanwhile the visitor sees the normal thank-you page. If you upgrade before then, they move into your form.

From the visitor's side a held message and a delivered one look the same. Someone asks for a quote on the 12th, sees "thank you" and waits. If you read it on the 1st, they've likely gone with someone else.

Formspark and Splitforms work differently in another way. Their free allowance, 250 and 500, is a total and doesn't come back next month. For a portfolio form that gets a message every few weeks that's plenty. A small shop will use it up.

Then there's us. When a Formgong account goes over, we keep delivering on credit until the 7th of the next month, up to 5,000 extra. That works once in any 12 months. If you go over again later in the year you get 20% on top, and after that new submissions wait until you upgrade or the month turns over. We took this from our code, not from a FAQ, but please check it like you'd check anyone else's claim.

When the limit stops more than the form

Netlify is a strange case. On its credit-based plans the forms are free and unlimited, so you'd think there's nothing to hit. But the plan has credit limits of its own, and Netlify's billing FAQ says that projects which go over them "will be paused and will no longer receive web requests, form submissions, etc." until the next billing cycle, unless you upgrade or switch on auto recharge. So when that happens, your whole site is down, and the form with it.

Jotform goes the other way and is loud about it. It disables the form, and anyone who opens it sees "This Form Has Exceeded Its Allocated Quota". You've lost the form until the month resets, sure. Nobody walks away thinking their message got through, though.

When the vendor's own pages don't answer

We couldn't pin down four of them.

Basin contradicts itself. The FAQ in its docs says free-plan submissions "may be restricted until the next month", while the pricing page says "We won't cut you off". Both still said that when we looked again on the 29th. FormBackend only promises that submissions "aren't dropped without warning", which doesn't tell you whether they're held or refused. With Web3Forms we got nothing: the docs don't cover it and the pricing page sent curl a 403 on both days. FormSubmit says it has no limit, and on the 29th we couldn't even re-read that, because the site was returning a Cloudflare 521.

If you're on one of these, ask their support, or watch the dashboard the first month you get close.

What to check on your own form

First, find your backend in the table and see where its warning emails go. Plenty of us signed up with some address we stopped reading years ago. If spam counts on your plan, turn on the spam filter or a captcha now, not after a bot has eaten the month. And send your form one request it should refuse (a wrong key is the easiest) and look at the page a visitor would get. It takes two minutes.

We wrote up the same 14 services in more detail, with how each answered a wrong key and where it keeps your data, in our form backend comparison.

Has a form limit ever cost you a lead? Or did you find a pile of old messages in an over-limit folder one day? Tell us in the comments which backend it was and how you found out. If a vendor behaves differently from what its page says, we'd like to hear that as well, so we can fix the table.

Our moderation model answers in 0.3 s or in 19 s, nothing in between. Hedged requests took us from 15/30 to 26/30

Formgong — Thu, 22 Oct 2026 13:56:14 +0000

We run a small AI help chat for websites, and every message in it passes a safety check before anything else happens. A visitor's question is classified by Llama Guard 3 (the 8B model, on Cloudflare Workers AI) before it reaches retrieval and the chat model, and the model's answer is classified again, together with the question, before it is shown and stored. Only an explicit "unsafe" verdict refuses the turn.

The chat streams its answers, so the check sits on the critical path. We gave it a budget of 3 seconds. Longer than that and the visitor is staring at a silent chat window wondering if it broke.

Then we measured the latency, on 2026-10-19, with 30 calls. It was bimodal in a way we hadn't seen from an inference API before: about half the calls came back in 0.1 to 0.3 seconds, and the rest took anywhere from 3 to 19 seconds. Almost nothing in between. A warm path and a cold path, presumably, though Workers AI doesn't say.

With that distribution, a single call against a 3-second timeout answered 15 times out of 30. A coin flip, which for a safety check is embarrassing: half of all turns went through unchecked purely because the classifier drew the slow path.

The fix is from a 2013 paper

Raising the timeout doesn't help. The slow path runs up to 19 seconds, so a timeout long enough to catch it makes the chat unusable, and any timeout short enough for the chat keeps losing the slow half.

What does help is noticing that the two paths are independent draws. If one call lands on the slow path with probability ~0.5, two calls both land on it with probability ~0.25. This is the "hedged request" from Dean and Barroso's The Tail at Scale: when a reply is slow, send the same request again and take whichever answer arrives first.

Ours starts a copy of the same classification every second while no call has answered, inside the same 3-second budget:

export const GUARD_TIMEOUT_MS = 3_000;
export const GUARD_HEDGE_MS = 1_000;

const call = () => ai.run(GUARD_MODEL, { messages, max_tokens: 20, temperature: 0 });
const copies = Array.from({ length: Math.ceil(GUARD_TIMEOUT_MS / GUARD_HEDGE_MS) - 1 }, (_, i) =>
  new Promise((resolve, reject) => {
    timers.push(setTimeout(() => call().then(resolve, reject), GUARD_HEDGE_MS * (i + 1)));
  }));
const out = await Promise.race([
  call(), ...copies,
  new Promise((_, reject) => {
    timers.push(setTimeout(() => reject(new Error(`timeout ${GUARD_TIMEOUT_MS} ms`)), GUARD_TIMEOUT_MS));
  }),
]);

So at most three calls race: the original, a copy at 1 s, a copy at 2 s. When the original draws the fast path (half the time), it answers in 0.3 s and no copy ever starts, because the timers get cleared in a finally. The copies only cost money on the turns that were about to fail anyway.

Same 30-call measurement, same 3-second budget, with hedging: 26 answers out of 30.

Two details that matter more than the race

Don't hedge errors. The first version of this raced everything, and that's wrong. A hedge is a bet that the same request will be fast the second time. That's true for a slow call, and false for a quota error or an outage, where the retry burns money to fail identically. So an error from any call ends the whole check at once; only silence gets hedged. In the code above that falls out of Promise.race naturally, since a rejection wins the race the same way a result does.

Decide what a missing verdict means before you ship. Hedging got us from 15 to 26 out of 30, not to 30. The remaining failures time out, and something has to happen with that turn. We fail open: the failure is logged and the turn continues unchecked, because for a help chat on a shop's website, a chat that goes mute whenever a classifier flakes is worse than one unchecked message. A moderation pipeline for user-generated content that stays up forever would reasonably make the opposite choice and fail closed. Either way, pick it deliberately; the default you don't choose is still a choice.

The measured numbers, for easy comparison, all on the same day with 30 calls each: fast path 0.1–0.3 s for about half the calls, slow path 3–19 s for the rest; one call inside 3 s: 15 of 30; hedged copies each second inside 3 s: 26 of 30.

This runs in production in Formgong's help chat, where the same check also writes the category of anything flagged into the message log. If you've dealt with bimodal inference latency on Workers AI or elsewhere, we'd like to hear what distribution you saw and what you did about it, and if you try the chat and something about it annoys you, tell us in the comments or at support@formgong.com.

A Playwright test that catches a contact form pretending to send

Formgong — Mon, 19 Oct 2026 13:00:00 +0000

A contact form that shows "Message sent!" and sends nothing looks exactly like one that works. Unit tests won't catch it, because there is nothing to unit test: the handler does exactly what it was written to do. You notice when a customer mentions they wrote to you weeks ago.

This isn't rare. We tested 105 contact forms on live sites built with AI tools like Lovable and Bolt, and 27 of them showed a success message without sending anything (the study and its data). The handler behind most of them looked roughly like this (a reconstruction of the pattern, not a copy of any one site):

const handleSubmit = async (e: React.FormEvent) => {
  e.preventDefault();
  setIsSubmitting(true);
  await new Promise((resolve) => setTimeout(resolve, 1000));
  toast({ title: "Message sent!", description: "We'll get back to you soon." });
  setFormData({ name: "", email: "", message: "" });
  setIsSubmitting(false);
};

There's a loading state, a delay, a nice toast and a reset. The one thing missing is a request.

Below are two Playwright tests that catch this, and the traps we fell into while building the browser harness for that study. The tests are much smaller than the harness, but the traps apply to both.

Test 1: the typed text must leave the page

The idea is to fill the form with a value nobody would type by accident, then look for that value in the outgoing requests. If no request carries it, the form didn't send what the visitor wrote, whatever the page says afterwards.

import { test, expect } from "@playwright/test";

// A value no real visitor types, so it is easy to find in any URL or body.
const MARK = "formcheck-7f3a91";

test("contact form sends what the visitor typed", async ({ page }) => {
  const carrying: string[] = [];

  await page.route("**/*", async (route) => {
    const req = route.request();
    const body = req.postData() ?? "";
    if (req.url().includes(MARK) || body.includes(MARK)) {
      carrying.push(`${req.method()} ${req.url()}`);
      // Answer it here, so CI never sends a real email.
      return route.fulfill({
        status: 200,
        contentType: "application/json",
        body: JSON.stringify({ success: true }),
      });
    }
    return route.continue();
  });

  await page.goto("/contact");
  await page.getByLabel("Name").fill("Form check");
  await page.getByLabel("Email").fill(`${MARK}@example.com`);
  await page.getByLabel("Message").fill(`Automated check ${MARK}`);
  await page.getByRole("button", { name: /send/i }).click();

  await expect.poll(() => carrying.length, { timeout: 5000 }).toBeGreaterThan(0);
});

The marker uses only letters, digits and a hyphen on purpose. They survive URL encoding and form encoding unchanged, so the same includes check works for JSON, FormData and application/x-www-form-urlencoded bodies. If you put the marker only in the email field, remember that @ becomes %40 in an encoded body, which is why the message field carries it too.

The fake response with success: true is a convenience. If your form talks to a real backend with a test mode, let that request through instead and assert on what the backend stored.

Test 2: no "thank you" when the backend fails

The first test proves something leaves the page. The second one proves the page doesn't celebrate too early. Make every POST fail and check that no success text appears.

test("no success message when the backend fails", async ({ page }) => {
  await page.route("**/*", (route) =>
    route.request().method() === "POST"
      ? route.fulfill({ status: 500, body: "" })
      : route.continue()
  );

  const dialogs: string[] = [];
  page.on("dialog", async (d) => {
    dialogs.push(d.message());
    await d.dismiss();
  });

  await page.goto("/contact");
  await page.getByLabel("Name").fill("Form check");
  await page.getByLabel("Email").fill("formcheck@example.com");
  await page.getByLabel("Message").fill("Automated check");

  const before = await page.locator("body").innerText();
  await page.getByRole("button", { name: /send/i }).click();

  // Sample for a few seconds: some toasts disappear after two or three.
  const seen = new Set<string>();
  for (let i = 0; i < 12; i++) {
    await page.waitForTimeout(250);
    const now = await page.locator("body").innerText();
    for (const line of now.split("\n")) {
      const t = line.trim();
      if (t && !before.includes(t)) seen.add(t);
    }
  }

  const appeared = [...seen, ...dialogs].join(" ");
  expect(appeared).not.toMatch(/thank|sent|success|received|get back to you/i);
});

Comparing against the text that was on the page before the click matters. Plenty of contact pages already say "We'll get back to you within a day" in their static copy, and a plain getByText would fail on that.

The traps

Our harness ran against hundreds of sites we didn't control, so it hit cases a test for your own site may never see. Still, each of these cost us a re-run, and a couple of them show up on ordinary sites.

Analytics requests. Clicking Send often fires Google Analytics, Tag Manager, Clarity, Hotjar or PostHog. If your test counts "any request after the click" as sending, every fake form passes. Looking for the marker instead of counting requests avoids this.

Alert dialogs. Some forms say thank you with alert(). Playwright dismisses dialogs automatically if you don't handle them, so the success message never reaches your assertions. That's why the second test listens for dialog.

Toasts that vanish. We had forms that showed "Message sent!" for two or three seconds. Reading the page once after a fixed wait missed them. Sampling every 250 milliseconds caught them.

Honeypots. A hidden field that only bots fill in. Some handlers show a fake success when it has a value, so a test that fills every input looks like a bot and gets a fake "thank you". Fill fields the way a person would, by label, and you won't touch the honeypot.

Hidden selects. shadcn/Radix select menus render a hidden native <select> that the form validates against. When our harness stopped filling hidden fields to avoid honeypots, these forms started refusing to submit. On your own site, select the option through the visible menu, or call selectOption on the native element with { force: true }, since Playwright won't act on a hidden element otherwise.

mailto: without a request. A form that does location.href = "mailto:..." opens the visitor's mail app and never makes a network request. Test 1 will fail on it, and that's arguably right: the site gets nothing unless the visitor actually sends that email.

Where this fits

Put both tests in the same CI job as the rest of your end-to-end suite and run them on every deploy. They take a few seconds. If you generate pages with an AI tool, they're worth even more, because a regenerated component can quietly swap a working handler for the pattern above.

For the backend side, the rule is the same one the second test enforces: show success only after the service that stores or delivers the message confirms it. We build Formgong, a form backend that answers with success: true only once a submission is stored, which is what the first test's fake response imitates.

Do you test your contact form in CI, or do you find out from customers? We'd like to hear how other teams handle it, and if one of these tests breaks on your stack, tell us where.

I checked 9 copy-paste HTML contact forms from the top search results. 4 send nothing

Formgong — Sat, 17 Oct 2026 15:55:36 +0000

Disclosure: I build Formgong, a form backend. Three of the pages below belong to companies like mine, and I say which.

If you search "html contact form code", you get pages with a form you can copy. I wanted to know how many of those forms would actually deliver a message if you pasted them into a site today.

On 13 October 2026 I took the top 10 pages for four searches ("html contact form code", "html contact form", "contact form html css", "simple contact form html"), merged by rank, skipping pages with no copyable code (a Scribd PDF, a Medium post with the code only as screenshots, and a page that now redirects to a form-builder tool). One page was down ("Site unavailable"), so 9 were judged. I wrote the checks down before opening the first page, and I only read the code. Nothing was submitted anywhere.

The checks

Does it send? The form has an action pointing at something that exists, or the page gives the backend code. action="#", no action, or JavaScript that only shows "Thanks" count as no.
Labels. Every field has a <label> tied to it. A placeholder alone doesn't count.
type="email" on the email field.
required on name, email and message.
autocomplete on name and email, so phones and password managers can fill them.
Any spam protection in the snippet: a honeypot, a captcha, a server check.
If JavaScript sends it: does it show an error when the request fails?

Results

Page	Owner	Sends	Labels	type=email	required	autocomplete	Spam
Formspree library	form backend	yes, after signup	yes	no	no	no	not in snippet
Medium (Cwrcode)	independent	no	no	yes	no	no	no
GeeksforGeeks	independent	yes (PHP)	no	yes	no	no	no
TemplateMonster Help (2011)	independent	yes (PHP)	no	no	no	no	no
freeCodeCamp	independent	no	no	yes	yes*	no	no
TutorialsPoint	independent	no	yes	yes	yes	no	no
a Lovable-built blog	independent	no	yes	yes	yes	no	no
Web3Forms	form backend	yes, after signup	no	yes	yes	no	not in snippet
Formcarry blog	form backend	yes	yes	yes	no	no	no (PHP version)

The totals:

5 of 9 send anywhere. Three of those five are form-backend companies, which is fair: sending is what they sell.
Of the 6 independent pages, 2 send, and one of the two can't be submitted as shown (see TemplateMonster below). So 1 of 6 gives code that delivers a message as pasted.
3 of the 4 forms that don't send never tell the reader.
0 of 9 set autocomplete. 0 of 9 have spam protection in the code itself. The three backend companies say they filter on their side; I didn't test that.
The only snippet that submits with JavaScript shows "Thank you" without making a request at all.

Four things worth seeing in the code

The fields have no names. The Medium post's form has inputs for name, email and phone, and none of them has a name attribute. Browsers only send fields that have a name. Even with a working backend behind it, the message would arrive with the country code and the text, and nothing that tells you who wrote it:

<input type="text" size="33" placeholder="Enter Your Name" id="firstname" autofocus />
<input type="email" id="eid" placeholder="Enter Your Email" size="33" />

The Send button disappears. The TemplateMonster article from 2011 shows its textarea with a <br> after it and no closing tag. A browser keeps reading everything after an unclosed <textarea> as its text, including the button. Parsed in Chrome, the form has zero submit buttons. Its PHP also builds the From and Reply-To headers from a variable the script never defines.

An empty message passes required. freeCodeCamp's form posts to action="#", so it sends nothing, and the tutorial doesn't mention that. The labels point at ids the inputs don't have. And the textarea ships with a space inside:

<textarea name="message" cols="30" rows="10" placeholder="Enter your message here ..." required> </textarea>

That space is the field's value, so the browser treats it as filled. In Chrome, validity.valueMissing is false for a message nobody typed.

Copy it as-is and you CC a stranger. GeeksforGeeks is the one independent page whose code would deliver, on a PHP host where mail() works. Its PHP adds a fixed header:

"CC: somebodyelse@example.com";

Paste it unchanged and every message also goes to example.com.

One more, from a backend company's own page: Formcarry's PHP example checks the name and email with patterns that reject o.brien+site@gmail.com, ann@studio.agency, José García and Олена Коваль. I tested the two patterns with Python's re, not PHP, because PHP isn't installed on my machine.

What a contact form that works needs

This is the checklist I'd use before pasting any snippet:

<form action="https://your-endpoint.example/submit" method="POST">
  <label>Name <input name="name" required autocomplete="name"></label>
  <label>Email <input type="email" name="email" required autocomplete="email"></label>
  <label>Message <textarea name="message" required></textarea></label>
  <!-- honeypot: hidden from people, bots fill it, the server drops those -->
  <div hidden><label>Leave empty <input name="botcheck" tabindex="-1" autocomplete="off"></label></div>
  <button type="submit">Send</button>
</form>

An action that points at something that really sends. Then send yourself one test from the live page and check the inbox.
A name on every field. Without it the value never leaves the browser.
Labels wrapped around or tied to each field, type="email", required, and autocomplete.
No whitespace between <textarea> and </textarea>.
Some spam check, even a honeypot.
If you send with fetch, show an error when the request fails. A "Thanks" that appears no matter what is worse than no form.

We put these rules into the free form generator on our site. It writes the same form as HTML, Tailwind, Bootstrap, React or Vue. It posts to Formgong, so it needs a key (there's a free plan). If you have your own backend, copy the markup and change the action.

To check a form that is already live, paste the page address into our form checker. It reads the page's HTML and reports a missing action, fields without names or labels, a lost submit button and a whitespace-filled required textarea. It works with any form backend and never submits anything.

The method, the full results and the failing line from every snippet are in a public repo: formgong/html-snippet-study. If you want a page I didn't quote, ask in the comments.

Tell me what I missed

Which tutorial did you copy your first contact form from, and did it work? If you know a snippet that passes all seven checks, post it below. I'll add it to the table.

CSP form-action also blocks the redirect after a form POST, and Chrome's error names the wrong URL

Formgong — Fri, 16 Oct 2026 13:00:00 +0000

Disclosure: I build Formgong, a form backend. We hit this bug on our own review page.

We were building a plain HTML page where customers leave a review: stars, a name, a text box, a submit button, no
JavaScript. The page has a Content-Security-Policy with form-action 'self'. The form posts to /submit, and the
server answers with a 303 back to a thank-you page.

In local development the redirect pointed at a different port. We pressed Send and nothing happened. The page didn't
move, the button didn't react, and Chrome's console said that sending form data to our own /submit violated
form-action 'self' and that the request had been blocked.

So we looked for the bug in the form's action URL. There wasn't one: /submit was on the page's own origin, which
form-action 'self' allows. What the browser had refused was the redirect that came after it, and the message didn't
say so.

We then tested this properly on 10 October 2026: seven cases, three browser engines, with the expected result for every
case written down before the first run.

The setup

Three origins on one machine, so that "same origin" and "other origin" are real: A (the page), B (a form endpoint), C
(somewhere else). The endpoint counts every POST it receives, so we know whether the data arrived regardless of what
the page shows.

// one tiny server per origin: A = :4601, B = :4602, C = :4603 (from run.cjs)
http.createServer((req, res) => {
  const url = new URL(req.url, origin(name));
  if (req.method === "POST" && url.pathname === "/submit") {
    posts[name]++;                                  // the data arrived
    req.resume();
    const to = url.searchParams.get("to");
    const code = Number(url.searchParams.get("code") || 303);
    if (!to) { res.writeHead(200, { "content-type": "text/html" }); return res.end("<p id=done>received</p>"); }
    res.writeHead(code, { location: code === 307 ? `${origin(to)}/submit` : `${origin(to)}/done` });
    return res.end();
  }
  // GET /case?id=N serves the form with that case's Content-Security-Policy header
}).listen(PORTS[name], "127.0.0.1");

<!-- the page, served with e.g.  Content-Security-Policy: form-action 'self' -->
<form method="POST" action="http://127.0.0.1:4601/submit?to=B&code=303">
  <input name="message" value="hello"><button>Send</button>
</form>

Each case ran in a fresh browser context: Google Chrome 154.0.8037.99, and Playwright's builds of Firefox 155.0 and
WebKit 26.6 (Safari's engine), all driven by Playwright. We clicked Send, waited 2.5 seconds, and recorded the final URL,
the POSTs each origin received, the console, and the securitypolicyviolation event.

Results

"Stays" means the page didn't navigate. The numbers are POSTs the server actually received.

#	Page CSP	Form posts to	Server answers	Chrome 154	Firefox 155	WebKit 26.6
1	`form-action 'self'`	A	303 → A	navigates, A got 1	navigates, A got 1	navigates, A got 1
2	`form-action 'self'`	A	303 → B	stays, A got 1	navigates, A got 1	stays, A got 1
3	`form-action 'self'`	B	(never asked)	stays, 0	stays, 0	stays, 0
4	`form-action 'self' B`	B	303 → A	navigates, B got 1	navigates, B got 1	navigates, B got 1
5	`form-action 'self' B`	B	303 → C	stays, B got 1	navigates, B got 1	stays, B got 1
6	`default-src 'self'` only	B	303 → C	navigates, B got 1	navigates, B got 1	navigates, B got 1
7	`form-action 'self'`	A	307 → B	stays, A 1, B 0	navigates, A 1, B 1	stays, A 1, B 0

We ran it twice. In the first run Chrome's case 3 timed out, because Playwright waited for a navigation that a blocked
form never starts. We counted that case as void rather than as a result and reran everything. The 20 cases both runs
share came out the same.

Three things that will cost you an afternoon

1. The data arrives, and the page acts as if it didn't. In cases 2 and 5, Chrome and WebKit send the POST, the
server stores it, and the browser then refuses to follow the redirect. The visitor sees the same form with the same text
in it and no error. If they press Send again, that's a second POST, and you store the submission twice.

2. Chrome's message points at the wrong URL. For case 2, Chrome prints:

Sending form data to 'http://127.0.0.1:4601/submit?to=B&code=303' violates the following Content Security Policy
directive: "form-action 'self'". The request has been blocked.

That is word for word what it prints for case 3, where nothing was sent (only the URL differs). The URL it names is the
form's action, which is allowed. The securitypolicyviolation event does the same: its blockedURI is the action URL
in both Chrome and WebKit. Only WebKit's console names the real culprit:

Refused to load http://127.0.0.1:4602/done because it does not appear in the form-action directive of the Content
Security Policy.

3. Firefox didn't check the redirect in any of our cases. Firefox 155 blocked the direct case (3), but in cases 2, 5
and 7 it followed the redirect as if form-action weren't there. With a 307 it went further and re-sent the POST body
to the other origin (case 7, B got 1). If you test in Firefox, the form works. Your Chrome and Safari visitors then get
the frozen page.

One more thing to know, since it shows up in case 6: form-action does not fall back to default-src. A policy with
only default-src 'self' lets a form post and redirect anywhere, in all three engines. MDN's form-action page says
the same: no default-src fallback, and "Not setting this allows anything."

The spec hasn't settled this either. Whether form-action should apply to redirects is
issue #8 in the w3c/webappsec-csp repo, "CSP: form-action and redirects", filed in 2015 and still open when I checked
on 13 October 2026. MDN's page warns that implementations are inconsistent.

Fixing it

form-action has to allow every URL the submission passes through: the action and every redirect after it. In practice:

Redirect back to the page's own origin. If the endpoint is yours, send the visitor to a thank-you URL on the same origin as the form. That is what we did: the form posts to /submit and returns to the same review page with ?sent=1.
List the redirect target. If the endpoint sends visitors to another domain (a payment page, a hosted thank-you page), that origin goes into form-action too, not just the endpoint's.
Or don't navigate at all. Submit with fetch() and show the result on the page. form-action doesn't apply to fetch(); connect-src does, and since the page never navigates, form-action never sees a redirect.

Check the result in Chrome or Safari, not Firefox. Watch the server's log as well as the browser's console: if the server
received the POST and the page didn't move, the redirect is the problem, whatever the console says.

We found this while building a review page for Formgong, a form backend for static and
AI-built sites. The test plan was written before the run, and we kept the raw results of both runs, every console line
included.

Your turn

Have you seen this in another browser, or with a different redirect code? Tell me in the comments and I'll add it to the table. And if you try Formgong for your own forms, I'd really like to hear what's missing or confusing.

A WordPress contact form block that does not use your host's mail

Formgong — Wed, 14 Oct 2026 13:00:00 +0000

Disclosure: I build Formgong. Our WordPress plugin went live in the official directory on 13 October 2026, so part of this post is about it. Everything I say about the other plugins comes from their own pages and source code, checked the same day.

The search "wordpress contact form block" mixes two different blocks.

On WordPress.com, the block you get from the inserter is Jetpack's Form block. The WordPress.com support page (last reviewed on 14 August 2026) says to search for "form" and pick a layout: Contact, RSVP, Registration, Appointment, Feedback, or Multistep. Responses are collected under Jetpack → Forms. If you don't see the block, the same page says you may be on a WordPress.org site, and you need to install the free Jetpack plugin.

That's a good answer when you want the replies inside WordPress.

It's a bad answer when the thing that fails is your host's mail.

Where the notification email comes from

On a self-hosted site, every block I looked at ends in the same function. I checked each one on 13 October 2026:

Jetpack Forms. In the Jetpack repo on GitHub (trunk), class-feedback-email-renderer.php wraps core \wp_mail() to send the notification.
Contact Form Block (Jordy Meow, version 1.1.1). In the plugin's classes/core.php, the default recipient is get_option( 'admin_email' ), and the message goes out with wp_mail( $form['to'], ... ).
Flinkform (version 1.15.0). Its directory page says notifications are "Sent through your site's standard WordPress mail (wp_mail)".

So if wp_mail() on your host doesn't deliver, swapping one of these blocks for another changes nothing. You get a new form that fails the same way. Jetpack and Flinkform keep a copy of each submission in WordPress, so the lead isn't lost, but nobody gets an email about it.

A thank-you line under the button is not proof. Send one test from the live page and read the inbox.

Two directory plugins that show up for the same search

I did not install these. The facts below are from their directory pages and the WordPress.org plugin API on 13 October 2026.

Contact Form Block, version 1.1.1, emails the site admin by default. Its page says a honeypot and a signed timestamp are on by default, and the 1.1.1 changelog (dated 2026/10/10) says posts sent directly to the site or in under 3 seconds are rejected. It says it loads no JS or CSS files unless you turn on reCAPTCHA. The API lists 600 active installations.
Flinkform, version 1.15.0, stores submissions in its own database table and emails you through wp_mail. It offers conditional logic and multi-step forms in the free plugin, and says it ships under 15 KB of gzipped frontend JavaScript. That size is their claim; I didn't measure it. The API lists 20 active installations.

If your host's mail works, either is a reasonable pick. If you need conditional rules that you write yourself, Flinkform has them for free. Pair it with an SMTP plugin if your host's mail is the weak spot.

What the Formgong block does instead

The Aula template on a published page, Storefront theme.

Formgong is a third option, and a narrow one: no form builder, and no submissions stored in WordPress.

The plugin adds a block called Formgong form (formgong/form) and a shortcode. The block has a template picker in the sidebar. The shortcode looks like this:

[formgong]
[formgong template="aula"]
[formgong product="1"]

The form is a plain HTML form. The visitor's browser posts it straight to https://formgong.com/submit, and Formgong sends the notification. The plugin's PHP never calls wp_mail(). I grepped the 1.0.1 source to be sure. The only request the plugin makes from your server is the admin's "Send a test submission" button, and that goes through wp_safe_remote_post().

Stripped down, the default form renders like this:

<form class="formgong-form formgong-skin-plain" action="https://formgong.com/submit" method="post">
  <h2>Contact us</h2>
  <input type="hidden" name="access_key" value="YOUR-ACCESS-KEY">
  <input type="hidden" name="_lang" value="en">
  <input type="hidden" name="_page_url" value="https://example.com/contact/">
  <label>Name <input type="text" name="name" autocomplete="name" required></label>
  <label>Email <input type="email" name="email" autocomplete="email" required></label>
  <label>Message <textarea name="message" required></textarea></label>
  <div class="formgong-trap" aria-hidden="true"><label>Leave this field empty<input type="text" name="botcheck" tabindex="-1" autocomplete="off"></label></div>
  <button type="submit">Send</button>
</form>

About that markup:

The access key is public. Anyone can submit with it, and it can't open the inbox. You paste it under Settings → Formgong.
botcheck is the spam honeypot. It is hidden from visitors and should stay empty.
_page_url is scheme, host and path only. The plugin drops the query string on purpose, because on a WooCommerce order page it can hold the order key. With the default referrer policy, a cross-origin post often carries only the site's origin as the referrer, so this field is what records the real page.

The bundled catalog has 55 templates: 22 website templates, 7 starter layouts, 1 NPS survey and 25 industry forms (clinic appointment, insurance quote, returns, RSVP and so on). The slug plain forces the built-in contact form above. Labels follow the site language in 12 languages, and anything else falls back to English.

The test button tells you when the key is wrong

Settings → Formgong: the key, the template and the redirects.

The "Send a test submission" button posts a fixed message from plugin-test@example.com and shows Formgong's answer as an admin notice. A typo in the key doesn't pass quietly. I sent an unknown key to the live endpoint on 13 October 2026, and it answered HTTP 404 with:

{"success":false,"code":"unknown_access_key","message":"That access key does not exist."}

The plugin shows that as "Formgong did not accept the test (unknown_access_key): That access key does not exist." The test does not finish the connect wizard in the Formgong dashboard. A real submission from the public page does that.

WooCommerce

On a store, the same plugin can add two optional forms:

a question on the product page, sent with the product name, SKU and URL;
a question on the customer's order page, sent with the order number. It only shows to a user who passes current_user_can( 'view_order', $order_id ), and not on the confirmation page right after checkout.

Checkout, payments and WooCommerce's order emails stay in WooCommerce. The plugin doesn't touch them.

What the free plan covers, and what's missing

From our plan limits in code and the live pricing page, on 13 October 2026:

300 submissions a month, unlimited forms.
Every submission emailed to one address. Telegram is instant on every plan.
One webhook per form, 30-day retention.
No auto-reply to the visitor on Free.

The site says the data stays in the EU, outside your WordPress database.

Now the limits. The plugin's forms have no file fields. Its forms don't show Cloudflare Turnstile either, so if Turnstile is on for that form in the Formgong dashboard, every submission is rejected with turnstile_missing. Turn it off for that form. The honeypot and Formgong's own spam checks still run. Some industry templates show a field only after a certain answer (the clinic form asks for a child's name only when the visit is for a child), but you can't write your own rules in WordPress, and there's no card payment. If you need those, stay with a builder.

Install

In WordPress, open Plugins → Add New, search for "Formgong", click Install Now, then Activate. The directory page is https://wordpress.org/plugins/formgong/. It went live on 13 October 2026, so it is brand new.

If your site can't reach the directory, download https://formgong.com/downloads/formgong-wordpress.zip and upload it under Plugins → Add New → Upload Plugin.

Then open Settings → Formgong, paste the key, click Send a test submission, and add the block. Setup notes, including the full template list: https://formgong.com/en/docs/wordpress/?ref=devto

If the form you already have is Contact Form 7 and it works, don't rebuild it just to reach Telegram. Send the form you have to a webhook instead. The CF7 to Webhook plugin can post it to a Formgong inbound URL, and Free allows three of those per form.

Tell me what's missing

If you run a WordPress site or build them for clients: what annoys you most about contact forms today, and what would make you switch to a plugin like this? Write it in the comments. I read every one, and the next version is shaped by them.

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.

Update, 16 October 2026: we ran the same tests again on 13 form backends and added what each free plan does with a message that arrives after the monthly limit. The full side-by-side table is here: Best form backend services, tested side by side.

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

What happens to a form submission after the free limit runs out

Four of them throw the message away

The ones that keep it

When the limit stops more than the form

When the vendor's own pages don't answer

What to check on your own form

Our moderation model answers in 0.3 s or in 19 s, nothing in between. Hedged requests took us from 15/30 to 26/30

The fix is from a 2013 paper

Two details that matter more than the race

A Playwright test that catches a contact form pretending to send

Test 1: the typed text must leave the page

Test 2: no "thank you" when the backend fails

The traps

Where this fits

I checked 9 copy-paste HTML contact forms from the top search results. 4 send nothing

The checks

Results

Four things worth seeing in the code

What a contact form that works needs

Tell me what I missed

CSP form-action also blocks the redirect after a form POST, and Chrome's error names the wrong URL

The setup

Results

Three things that will cost you an afternoon

Fixing it

Your turn

A WordPress contact form block that does not use your host's mail

Where the notification email comes from

Two directory plugins that show up for the same search

What the Formgong block does instead

The test button tells you when the key is wrong

WooCommerce

What the free plan covers, and what's missing

Install

Tell me what's missing

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()`