How to test a contact form, end to end

Why does a contact form break without anyone noticing?

You almost never use your own contact form. Visitors do, and when it breaks they rarely tell you, because from their side it often looks fine. A redesign moves the button. Someone renames a field and drops its name. A script shows “Thanks!” before it knows whether anything was sent. The page still looks finished, and the only sign of trouble is the messages that stop coming.

It happens more than people expect. When we pressed send on 105 contact forms on Lovable and Bolt sites, 27 showed a success message and sent nothing at all; the details are in contact forms that send nothing. So the question is not whether to test, but which test catches which kind of break.

Which faults did each test catch?

We wrote nine small contact pages. One was healthy. Each of the other eight had a single fault of the kind that breaks real contact forms. Then we ran five checks on every page in Chromium 153, against a local copy of Formgong's form backend, and wrote down whether a person running that check would have noticed the fault.

The pattern is the useful part. Reading the HTML finds structural mistakes in seconds, without sending anything, but it cannot know that an old endpoint now returns 404 or that a script lies about success. A real send finds those, but a form with no validation and placeholder labels sends perfectly well, so sending alone looks healthy. You need both, and the two together found every fault we planted.

How do you test a contact form step by step?

Start with the HTML, because it is free and it changes nothing. Paste the page address into the form checker and read what it says about each form. It flagged 6 of our 8 faults, including the two that a real send would have hidden from you: the unlabelled fields and the missing email type.

Then send one real message with an address you read yourself, and put a unique word in it, such as the date and time. Do not stop at the thank-you page. Open the place where messages land, your inbox and your form dashboard, find that word, and compare every field with what you typed. The form with the dead URL showed up only here, because it looked fine until nothing arrived. The form with the unnamed message box said thank you and delivered a submission with no message in it, which you only notice if you read the submission itself.

Next, send something wrong on purpose: an email like emma@ and an empty message. A healthy form stops you in the browser or answers with an error. Our form without validation took both and passed them on, which is how junk ends up in your inbox. Field checks on the server are the second line here; our article on server-side form validation shows why the browser alone is not enough.

Finally, make the send fail. In Chrome DevTools, the Network panel can block a single request URL; block your form endpoint and press send again. The visitor should see that it did not work. Two of our eight pages still said “Thanks!”, and on a real site those visitors would leave believing you have their message. If something does fail for real, contact form not sending email walks through where the message stopped.

// contact-form.spec.js: one end-to-end check with Playwright.
// Run it against staging, or against production with a test address
// you read yourself, and look the message up in your inbox afterwards.
import { test, expect } from "@playwright/test";

test("the contact form sends what was typed", async ({ page }) => {
  const marker = "form-test-" + Date.now();
  await page.goto("https://www.example.com/contact");
  await page.getByLabel("Name").fill("Emma Clarke");
  await page.getByLabel("Email").fill("emma.clarke@example.com");
  await page.getByLabel("Message").fill("Test message " + marker);

  const sent = page.waitForRequest((request) =>
    request.method() === "POST" && (request.postData() ?? "").includes(marker));
  const answered = page.waitForResponse((response) => response.request().method() === "POST");
  await page.getByRole("button", { name: "Send" }).click();

  // The message must leave the page, and the server must accept it.
  await sent;
  expect((await answered).status()).toBeLessThan(400);
  console.log("Now find", marker, "in your inbox and dashboard.");
});

Can you test a form without sending a real message?

Yes, with a limit you should know about. A live check opens the page in a real browser, fills the form with test values, presses send and blocks every request, so nothing reaches the owner. That is the right tool for a client's site or any form you do not want to fill with test mail, and it caught the two faults that need a browser to see: the fake “Thanks!” and the button that had moved out of the form.

It passed the other forms, and that is not a bug. Because it blocks the request, it only learns that a request carrying your message tried to leave. Whether the server would have accepted it, or answered 404, or rejected a mistyped key, stays unknown. In our run it rated 6 of the 8 broken forms as sending. Use it to answer “does this form send at all?”, then confirm delivery with one real message. How we built and checked that browser test is in how we tested contact forms.

What does Formgong's form checker do that a test checklist does not?

The two guides we read on 3 November 2026 cover testing your own form well, but both assume you can send real submissions. Splitforms' “How to Test Form Submissions Without Sending Real Emails” (updated 29 September 2026) says its service has no test mode, and its dashboard's test submission is a real one that counts like any other. Static Forms' “Form QA: A Complete Testing Checklist for Static Sites” (2 August 2026) is a checklist plus Cypress and Playwright scripts you write and run yourself. Formgong's form checker works from the outside, on any public page, including forms that do not use Formgong: it reads the HTML, and its live test presses send in a remote browser with every request blocked. If the form is yours, it can also send one test submission with your page's own address as the origin, so the allowed-domains setting is tested the way a visitor would hit it. That is the same pair that caught all 8 faults above, the HTML check and a real send, without you writing a script. The fields Formgong reads are listed in the HTML forms docs.

Did your form break in a way we did not test?

If you have found a contact form fault that none of these checks would catch, write to support@formgong.com. We will plant it in a test page, run the checks again and add it to the table.