Send request parameters

How do values reach the server in an HTMX request? The answer is reassuring: HTMX follows normal form rules. If you know how a plain HTML form submits, you already know what HTMX sends.

A form sends its successful named controls — the controls that have a name and are in a submittable state:

<form action="/tasks" method="post" hx-post="/tasks">
  <label>
    Task
    <input name="title" required>
  </label>

  <label>
    <input type="checkbox" name="urgent" value="yes">
    Urgent
  </label>

  <button name="intent" value="create">Add task</button>
</form>

The server receives title, receives urgent=yes only when checked, and receives the clicked submit button’s intent. Submitting with the task “Buy milk” and the checkbox ticked produces a body like this:

title=Buy+milk&urgent=yes&intent=create

An unnamed control is not submitted, no matter what the user typed into it. A disabled control is not submitted either. Both rules come from HTML, not from HTMX, and both produce the same silent symptom: a value that looks fine on screen and never arrives at the server. When a field is mysteriously missing from a request, check its name attribute and its disabled state before anything else.

The method decides where the values travel. A GET encodes values in the query string, so they appear in the URL. A POST normally uses the request body according to the form encoding. The server must parse repeated names correctly for multi-select controls and checkbox groups, where tag=a&tag=b is two values for one field, not a mistake.

Do not infer the payload from what appears on screen. Inspect the Network panel’s query string or form data, then log only safe field names on the server while debugging. Client values remain untrusted even when browser validation ran first: anyone can send any parameters to your endpoint without using your form at all.

Add a name to one control and remove it from another, then submit and compare the two requests in the Network panel.