Without using any framework, how do you take over a form's submission and send it with fetch while sending exactly the data the browser would have sent, and what is the form's formdata event for?

## Start from markup that already works A form that only functions once script has loaded and run is a form that is broken during the load, after a script error, and on a flaky connection. So write the real thing first: ```html <form id="signup" action="/api/signup" method="post"> <label for="email">Email</label> <input id="email" name="email" type="email"> <button name="intent" value="create">Create account</button> </form> ``` Then enhance it, reading the destination out of the markup rather than repeating it in JavaScript. `form.action` and `form.method` give you exactly what the browser would have used, so the two paths cannot drift apart. ## Reproducing the browser's entry list ```js const form = document.querySelector("#signup"); form.addEventListener("submit", async (event) => { event.preventDefault(); const data = new FormData(form, event.submitter); const response = await fetch(form.action, { method: form.method, body: data }); // handle response… }); ``` Three details carry most of the value here. **`new FormData(form)` walks the form's controls** using the same rules the browser uses natively: named, enabled controls only, unchecked boxes skipped, controls attached with the `form` attribute included. That is why it is the right way to collect values — it cannot drift from what a native submit would have produced. **The second argument is the submitter.** Without it, the activated button's `name`/`value` is missing, so a form with `intent=create` on the button silently stops sending `intent` the moment you enhance it. `event.submitter` is the element the browser recorded as triggering submission — the clicked button, or the default button when the user pressed Enter. **Do not set the `Content-Type` header.** Passing a `FormData` object as a `fetch` body makes the browser encode it as `multipart/form-data` and generate the boundary token that the receiver needs to split the parts. Writing the header yourself ships a content type with no boundary and the server cannot parse the body. If the endpoint expects `application/x-www-form-urlencoded`, convert instead: ```js const body = new URLSearchParams(data); // text entries only ``` URLSearchParams has nowhere to put a file, so this only applies to text forms. ## Reading values out of a FormData `get(name)` returns the first entry, `getAll(name)` returns every entry with that name, and `has`, `append`, `set` and `delete` do what they say — with the important distinction that `append` adds another entry while `set` replaces all existing ones. The convenient-looking `Object.fromEntries(data)` is a trap for checkbox groups and any repeated name: an object can hold one value per key, so all but the last are dropped. Use `getAll` for anything multi-valued. And if the endpoint wants JSON, remember that `JSON.stringify(formData)` produces `{}` — you have to build the object yourself. ## What the formdata event is for `formdata` fires **on the form** every time its entry list is constructed — during a native submission *and* when script calls `new FormData(form)`. The handler receives an event whose `formData` property is the list being built, and mutating it changes what gets submitted: ```js form.addEventListener("formdata", (event) => { event.formData.append("signature", canvas.toDataURL()); event.formData.append("clientTimezone", Intl.DateTimeFormat().resolvedOptions().timeZone); }); ``` The point is decoupling. A custom control — a drawing canvas, a rich text editor, a map picker — holds state that no form control owns. The old approach was to keep a hidden input in sync with it, which means the widget must know about the form's markup and every place that mutates the widget must remember to update the input. With `formdata`, the widget registers one listener and contributes its value at exactly the moment the value is needed, and it works whether the form is submitted natively or collected by script. The event is not cancelable — it is a hook for contributing entries, not a validation gate, and it is not the place to block a submission. ## What you inherit responsibility for Once you call `preventDefault`, the browser stops doing several things it used to do for you: showing progress, disabling nothing while the request is in flight, and navigating on success. You now own the pending state, the double-submit guard, the error path when `fetch` rejects, and telling assistive technology that something happened — which is what a live region is for. If you disable the submit button while the request runs, disable it *after* you have built the `FormData`, because a disabled named button would otherwise drop out of the entry list.