JMeter HTTP Samplers: Configure Every Request Type (2026)

JMeter HTTP Samplers can actually make requests beyond just GET and POST, and most people are leaving powerful options on the table.

Let’s watch this GET request, for example. It’s hitting an API endpoint that’s supposed to return user data.

{
  "request": {
    "method": "GET",
    "url": "http://localhost:8080/users/123",
    "headers": {
      "Content-Type": "application/json"
    }
  },
  "response": {
    "status": 200,
    "body": {
      "id": 123,
      "name": "Alice",
      "email": "alice@example.com"
    }
  }
}

Here’s the JMeter setup for that:

• HTTP Request Sampler:
  • Name: Get User Data
  • Server Name or IP: localhost
  • Port Number: 8080
  • Method: GET
  • Path: /users/123
  • Content encoding: UTF-8

Now, what if we need to, say, delete that user? Most folks would just create a new HTTP Request Sampler, change the method to DELETE, and point it at the same URL. But what if the API requires a specific Content-Type header for the DELETE, or maybe even expects a request body to confirm the deletion?

This is where understanding the full capabilities of the HTTP Request sampler becomes critical. You’re not just telling JMeter what to ask for, but how to ask for it, and what to send along with the request.

Let’s configure a DELETE request. Suppose the API requires a Content-Type: application/json header and a JSON body like {"confirm": true} to initiate the deletion.

• HTTP Request Sampler:
  • Name: Delete User Data
  • Server Name or IP: localhost
  • Port Number: 8080
  • Method: DELETE
  • Path: /users/123
  • Content encoding: UTF-8
  • Parameters:
    • Add | Name: Content-Type | Value: application/json
  • Body Data:

    {
      "confirm": true
    }
    

This sampler will now send a DELETE request to http://localhost:8080/users/123 with the specified Content-Type header and the JSON body.

Beyond GET, POST, and DELETE, JMeter’s HTTP Request sampler also directly supports:

• PUT: Commonly used for updating resources. You’d configure it much like the DELETE example, but with PUT as the method.
• HEAD: Retrieves only the headers of a response, not the body. This is useful for checking resource existence or metadata without transferring large amounts of data.
  • HTTP Request Sampler:
    • Name: Check Resource Headers
    • Server Name or IP: localhost
    • Port Number: 8080
    • Method: HEAD
    • Path: /users/123
• OPTIONS: Retrieves the communication options available for a target resource. This is often used to check what HTTP methods are allowed on a given URL.
  • HTTP Request Sampler:
    • Name: Get Allowed Methods
    • Server Name or IP: localhost
    • Port Number: 8080
    • Method: OPTIONS
    • Path: /users/123
• TRACE: Performs a message loop-back test along the path to the target resource. It’s primarily for diagnostic purposes.
  • HTTP Request Sampler:
    • Name: Trace Request Path
    • Server Name or IP: localhost
    • Port Number: 8080
    • Method: TRACE
    • Path: /users/123

The "Parameters" tab in the HTTP Request sampler isn’t just for query parameters in GET requests. When you select a method that can have a body (POST, PUT, DELETE), and you don’t put anything in the "Body Data" field, JMeter will serialize the parameters you define in the "Parameters" tab into the request body, typically as application/x-www-form-urlencoded data. However, for application/json or other content types, you must use the "Body Data" tab.

The true power lies in how JMeter maps these HTTP methods to their intended semantics in RESTful APIs and other HTTP-based protocols. By explicitly choosing the correct method, you’re not just mimicking a client; you’re correctly signaling intent to the server, which can impact how the server processes the request, handles idempotency, and manages resources. For instance, a PUT request is designed to be idempotent – multiple identical PUT requests should have the same effect as a single request. A POST request, on the other hand, is not necessarily idempotent. JMeter’s direct support for these methods allows you to accurately model these behaviors.

When you use the "Body Data" tab, JMeter sends that exact string as the request body. If you also add parameters in the "Parameters" tab, JMeter will send both. This is a common point of confusion; if you intend to send JSON in the body, you should generally leave the "Parameters" tab empty unless you specifically need to append query parameters to the URL itself (which is less common for PUT/POST/DELETE).

The flexibility of the HTTP Request sampler goes beyond just selecting a method. You can meticulously control headers, cookies, and even the request body’s content type and encoding, allowing you to simulate a vast array of client interactions with web services.

The next hurdle you’ll likely face is orchestrating these diverse requests in a meaningful sequence, which leads directly into understanding JMeter’s Thread Groups and Logic Controllers.