The Check That Runs in Your Browser

Stage: the form, before anything is sent. In control: your browser.

1. The check in your browser does not decide whether the address is acceptable

Everything the browser does to your address happens on your machine, and none of it settles anything. It catches an empty field and an obvious typo, then gets out of the way. Whether the address is welcome is decided later, on a server you have not contacted yet, by rules you cannot see from here.

This matters because the browser is the only part of the process that talks to you. When a form turns red before anything has been sent, that is a local opinion, and local opinions are frequently wrong about addresses that work perfectly well.

2. The email field type tests less than its name suggests

Marking a field as an email field gives you a built-in check, and that check is deliberately minimal. It looks for something before an at sign and something after it. Browsers differ slightly in the details, which is its own small surprise: the same address can pass silently in one browser and produce a warning in another.

The most quoted example is that a@b passes. That is not a defect. It is a structurally legal address, because a bare hostname without a dot is legal, and the browser is not in a position to know whether such a host exists on your network. The field type was designed to catch mistakes and to raise the right keyboard on a phone, not to guard a database.

3. A pattern in the page script usually tightens the rules past the standard

Most forms add their own test on top, and almost all of those tests are stricter than the specification. They are written from memory, matched against the addresses the author has seen, and frozen at that point.

The casualties are predictable: long suffixes, apostrophes in the local part, the plus sign, and anything with unusual punctuation. All of them are legal, all of them deliver mail, and none of them survive a pattern written in five minutes. The full picture of what the standard permits and what forms accept is in what counts as a valid address, and it is worth having, because it converts an unexplained refusal into a known one.

4. The did you mean prompt compares your domain against a short list

When a form asks whether you meant a well-known provider, it is doing something simple: taking the domain you typed, measuring how close it is to a handful of common domains, and offering the nearest match when the distance is small.

It genuinely helps. Transposed letters, a missing letter and the wrong final letter are the mistakes people make while typing quickly, and this catches them before a message goes to a domain that does not exist. It also misfires, because distance is not intent. A small legitimate provider whose name resembles a large one gets flagged every time, and every user of that provider has learned to dismiss the prompt without reading it.

5. Autofill puts an address in the field faster than you can read it

Your browser stores addresses you have used and offers them the moment the field receives focus. One click, sometimes one keystroke, and the field is populated.

This is the most common way a permanent address ends up in a form that was opened specifically to keep it out. The sequence is quick and the field is small, so the substitution frequently goes unnoticed until the confirmation message lands in the wrong mailbox. The defence is unglamorous: look at the field after it fills, before you look at the button. If you have generated an address for this form, keeping the two visibly different makes the mistake obvious at a glance rather than invisible.

6. Client-side validation protects nobody, and it was never meant to

The code runs on your computer, which means it can be edited, bypassed or ignored by anyone who wants to, using tools that ship with the browser. Anything the site actually needs to enforce has to be enforced where the site is in control.

Reputable forms therefore repeat every check on the server, and the browser copy exists only to give you a faster answer. That division of labour is standard, and it is the reason the same address can be accepted by the browser and rejected a moment later. The two checks are unrelated pieces of code with different authors and, quite often, different rules. On the receiving side, the mismatch usually begins with how the address gets cleaned up and compared.

7. Three adjustments clear most refusals of a live address

When the form insists your working address is invalid, try them in order. Remove the plus sign and anything following it, since that is the single most commonly refused legal construction. Remove dots from the local part if your provider ignores them. And type the address by hand instead of pasting it, because a copied string can arrive with a trailing space or an invisible character that looks like nothing and matches nothing.

If none of those work, the problem is on the right side of the at sign, and the answer is a different domain rather than a different spelling. On a disposable service that takes one click.

The handover

The browser hands the address to the server intact and forms no further opinion about it. What follows is the site's own sequence of checks and the record it writes, described step by step in what happens the moment you submit. If the address survives that, the next thing you will see is a message asking you to click a link, and what that click actually proves is less than most people assume. To have an address ready before you meet the next form, generate one first.