Requests and responses

Use the request method attributes

Choose hx-get, hx-post, hx-put, hx-patch, or hx-delete to match the meaning of the server operation.

Each request attribute takes a URL and tells HTMX which HTTP method to use:

<button hx-post="/tasks">Create task</button>
<button hx-patch="/tasks/42">Complete task</button>
<button hx-delete="/tasks/42">Delete task</button>

Use the HTTP method to describe the operation:

  • hx-get retrieves a representation without changing server state
  • hx-post commonly creates a resource or performs a command
  • hx-put replaces a resource representation
  • hx-patch applies a partial change
  • hx-delete removes a resource

The attribute only declares a request. The server still needs a matching route, authentication, authorization, validation, and CSRF protection for state-changing methods. HTMX does not save you from any of that.

HTMX 2 sends values for DELETE in URL parameters by default, aligning it with the current specification behavior. Do not assume the request body format from an older HTMX version. Inspect the actual request in the Network panel and configure your server parser accordingly.

GET must remain safe because browsers, crawlers, caches, and prefetchers may repeat it. A route that deletes on hx-get is dangerous even if the current button is the only visible way to call it. I have seen hx-get used for “refresh list” and hx-delete on a separate control. Keep that separation clear in your markup and in your routes.

Open the Network panel and verify method, URL, and parameter location for each example. A PATCH that shows up as POST with a method override is a server framework detail, not an HTMX surprise, but you should know which pattern your stack uses.

Use GET for safe retrieval. Use a state-changing method for create, update, or delete actions.

Try this on your own project: list your HTMX routes and confirm no GET route mutates data.

Lesson completed