A login form has two inputs and a button. The code to submit it is about ten lines.
Behind that button there are at least a dozen separate systems, and any of them can be the reason your form "doesn't work." Most of us only debug the first and last ones.
This post follows one login request all the way down and back up. At each layer I'll cover what happens, what can break, and how to look at it yourself.
One caveat before we start. Steps 3 and 4 often don't happen. If the browser already has an open connection to that host, it reuses it and skips straight to sending the request. I'll show the full cold-start path because it's the most informative, but a warm request is much shorter. The click: from your finger to a fetch() call
Clicking the button doesn't send anything. The click fires a click event, which bubbles up the DOM. Its default action is to submit the enclosing form.
Before the submit event fires, the browser runs built-in constraint validation (required, type="email", pattern). If a field is invalid, the browser shows its error bubble and no submit event fires at all. That's why a handler you put on submit sometimes seems to be ignored.
Without preventDefault(), the browser does a native form submission: it builds the request itself and navigates to the response, reloading the page. That still works, and it's often the more robust choice, but most SPAs intercept it.
What can go wrong here: A handler throws before fetch() runs. preventDefault() is missing, so the page reloads and your state is lost. Validation blocks the submit and you never see an event. Before the request leaves: CORS, cookies, CSRF
CORS only matters if the request is cross-origin (different scheme, host, or port). A POST with Content-Type: application/json isn't a "simple" request, so the browser first sends an OPTIONS preflight asking the server whether this origin, method, and header combination is allowed. If the server doesn't answer correctly, the real request is never sent.
Two points that trip people up: CORS is enforced by the browser. curl will succeed against the same endpoint, which is a quick way to tell a CORS problem from a server problem. The server can receive the request and process it; the browser just refuses to hand you the response.
Cookies are attached automatically for same-origin requests, subject to SameSite, Secure, and domain rules. For cross-origin requests you need credentials: "include" and a matching server configuration.
CSRF is the reason session-cookie apps also need CSRF tokens or SameSite cookies: a malicious page can make the browser send your cookies to a site you're logged into. Authorization headers set by your own JavaScript aren't attached automatically, which is part of why token-in-header APIs are less exposed to CSRF (and more exposed to XSS if you store the token carelessly). Both models have trade-offs. DNS: finding the server
The browser has a URL, but it needs an IP address. It checks, in rough order: Its own DNS cache The OS resolver cache A recursive resolver (your ISP's, or something like 1.1.1.1 or 8.8.8.8) If the resolver doesn't have it cached: the root servers, then the TLD servers (.com), then the domain's authoritative nameserver
The result is cached according to its TTL, so most lookups never go past step 2 or 3.
Failure mode: a wrong or missing record, an expired domain, or a stale cache after a migration, which looks like "works for me, fails for them." Connection: TCP or QUIC, then TLS
Then TLS negotiates encryption: the server presents a certificate, the browser validates it against trusted authorities, and both sides derive session keys. With TLS 1.3, that's one extra round trip after TCP.
HTTP/3 runs over QUIC, which uses UDP. QUIC folds the transport and TLS 1.3 handshakes together, so a new connection needs fewer round trips.
Two honest caveats: Browsers keep connections open and reuse them. A returning user often skips this whole stage. TLS protects data in transit. It does nothing for how the password is stored in the database (step 8).