Inspect HTMX request headers

HTMX sends request context in HX-* headers. Open the Network panel on any HTMX click and look for:

• HX-Request: true
• HX-Trigger: the triggering element’s ID, when it has one
• HX-Trigger-Name: its name, when present
• HX-Target: the target’s ID, when present
• HX-Current-URL: the browser’s current URL
• HX-Boosted: true for a boosted request
• HX-History-Restore-Request: true after a history cache miss

The server can use these as rendering context. HX-Request often selects fragment versus full-page output. HX-History-Restore-Request tells the route that history restoration needs enough HTML to reconstruct the page. That is a useful hint, not a security token.

Do not make correctness depend on optional IDs. If HX-Target is absent, the route should still have a sensible representation. IDs are convenient when present, but your server logic should not break when a developer forgot to add id="task-list".

Every one of these headers can be forged by a script or command-line client. They do not prove identity, permission, CSRF validity, or that the request originated from your markup. Treat them like request hints in a log line, not like session credentials.

Copy the request as curl, change HX-Target, and send it again. The response may render differently. Authorization must not. If changing a header lets you see another user’s data or perform an action you should not perform, the bug is in the route, not in HTMX.

When I debug a route that behaves differently for HTMX and direct navigation, I compare the full header set side by side. Often the difference is HX-Request alone, and the fix is a small branch in the template renderer.

Try this on your own project: copy one HTMX request as curl, remove the cookie, and confirm the server still rejects unauthorized actions.