# How to test a contact form, end to end

Five ways to test a contact form from the outside, run on 8 forms that each had one planted fault, and which faults each check caught.

Author: Formgong
Published: 2026-11-03
Language: en
Canonical: https://formgong.com/en/blog/how-to-test-a-contact-form/

Test a contact form the way a visitor uses it: read its HTML, send a real message, then confirm the whole message arrived where you read submissions. In our test on 3 November 2026, 8 sample forms each had one planted fault. No single check caught more than 6 of the 8, but the HTML check and a real send together caught all 8.

## 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](/en/blog/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.

Eight planted faults and the checks that caught them, 3 November 2026. The healthy page passed every check.
Planted faultCaught by
The message box has no `name`HTML check (“fields without a name”); the inbox, where the message was missing
A script shows “Thanks!” and sends nothingLive check (fake success); real send (nothing arrived); endpoint failure (still said thanks)
A typo in the access key, and “Thanks!” whatever the server saysHTML check (key unknown); real send (refused, nothing stored); endpoint failure (still said thanks)
The action points at an old URL that returns 404Real send only
No validation: email is a text field, nothing requiredHTML check (email field type); bad input (“emma@” and an empty message were stored)
Placeholders instead of labelsHTML check only
A redesign moved the button out of the formHTML check (no submit button); live check (nothing to press); real send (nothing happened)
No `method`, so the browser sends a GETHTML check (form sent with GET); real send (nothing stored, message in the URL)
How many of the 8 faults each check caught
CheckFaults caught
HTML check (Formgong form checker)6 of 8
Real send, then read what arrived6 of 8
Live check (send pressed, every request blocked)2 of 8
Endpoint made to fail2 of 8
Bad input1 of 8
HTML check and real send together8 of 8
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](/en/tools/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](/en/blog/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](/en/blog/contact-form-not-sending-email/) walks through where the message stopped.

```javascript
// 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](/en/blog/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](/en/tools/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](/en/docs/html/).

## 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](mailto:support@formgong.com). We will plant it in a test page, run the checks again and add it to the table.

## Frequently asked questions

### How do I test a contact form without spamming my inbox?

Read the HTML first and use a live check that blocks every request. Then send one real message with a unique word in it to an address you control, and delete it afterwards.

### Is the thank-you page proof that a form works?

No. Two of our eight broken forms showed “Thanks!” even when the endpoint was down. Check that the message arrived complete where you read submissions.

### How often should I test my contact form?

After every change to the page, the form or its settings, and on a schedule, for example once a month, with one real message.

### What is the fastest contact form test?

Paste the page address into a form checker. In our test the HTML check caught 6 of 8 planted faults in seconds without sending anything.

## Sources and documentation

- [Formgong: Contact forms that send nothing](https://formgong.com/en/blog/contact-forms-that-send-nothing/)
- [Formgong: How we tested AI-built contact forms](https://formgong.com/en/blog/how-we-tested-contact-forms/)
- [HTML forms](https://formgong.com/en/docs/html/)

[Get a form key](https://formgong.com/en/#top)