A config element that supplies fallback values to every HTTP request in its reach.

JMeter test plans are made of several kinds of building blocks. Samplers send requests, logic controllers decide the flow, timers add pauses, assertions check responses and config elements provide shared settings. HTTP Request Defaults belongs to the last group. It does not send any request itself and it never appears in the results. Its only job is to hold values such as the server name, the protocol and the port, so that individual HTTP requests do not have to repeat them.

The mechanism is simple. When an HTTP Request sampler is about to run, JMeter looks at each of its fields. If a field has been filled in on the sampler, that value is used. If a field has been left blank, JMeter looks for a value in any HTTP Request Defaults element that applies to the sampler, and uses it if present. The sampler therefore carries only what is special about it, such as its own path, while everything common lives in the defaults.

What it is not

It is not a sampler, so it produces no sample and no timing. It is not a variable store, although it can read variables. It is also not a security feature or a firewall rule. It is purely a convenience and a consistency tool, but because it feeds every request, a single wrong value in it can corrupt an entire test run at once.

Three problems appear in every large test plan, and this element solves all three.

The first problem is repetition. A realistic journey can contain fifty or more requests, and every one of them targets the same application host. Typing the same host, protocol and port fifty times is boring, error-prone and noisy to read. Repetition also hides the one place where a request deliberately differs, because the real difference is buried in a sea of identical fields.

The second problem is maintenance. Applications move, hostnames change, ports are reassigned and protocols are upgraded from plain to secure. If the value is typed everywhere, each change is a search-and-edit job across the whole plan. With defaults, the change is made once, and every request follows instantly.

The third problem is portability across environments. Teams run the same script against development, testing, staging and sometimes production-like systems. A plan that hard-codes the host in every sampler is effectively bound to one environment. A plan that keeps the host in one defaults element can be pointed at any environment by changing a single value, or even by supplying it from outside at launch time.

The dialog mirrors the HTTP Request sampler, because it fills that sampler’s blanks.

The fields in HTTP Request Defaults deliberately resemble the fields in the HTTP Request sampler, which makes sense because the defaults supply values for them. They fall into a few groups. Learning the groups once makes the whole element easy to read.

Exact labels and layout can differ slightly between JMeter versions, so always read the dialog in your own installation. The ideas, however, stay the same: host settings, request settings, advanced network settings and embedded resource handling.

Understanding exactly when a default is used prevents most surprises.

The rule is applied field by field, not request by request. A sampler may inherit the server name from the defaults while overriding the path with its own and inheriting the timeout again. Each field is resolved independently. That granularity is powerful, but it also means that a single forgotten blank or an unexpected filled field changes the outcome for just that field.

flowchart TD
    A["Sampler is about to run"] --> B{"Is the field filled on the sampler?"}
    B -- "Yes" --> C["Use the sampler value"]
    B -- "No" --> D{"Does an applicable defaults element supply it?"}
    D -- "Yes" --> E["Use the defaults value"]
    D -- "No" --> F["Use the built-in fallback or leave empty"]
        

A classic surprise: the inherited port

Suppose the defaults hold a server name and a non-standard port, such as an internal service port. A tester then adds one sampler that targets a different host and fills in only the server name, forgetting the port. The sampler still has a blank port field, so it inherits the non-standard port from the defaults and tries to reach the second host on a port that host never listens on. The result is a confusing connection failure that looks like a network problem but is really an inheritance effect.

Protocol follows the same logic

A blank protocol on the sampler inherits the protocol from the defaults. A sampler that fills in a protocol overrides it. When the defaults say secure and a sampler says plain, the sampler wins, which can quietly send some requests unencrypted through a path the application redirects. Always inspect the final resolved address of a few requests in the results to be sure each one went where you intended.

Where you put the element decides which requests it can feed.

A JMeter plan is a tree, and config elements follow scoping rules based on their position. A defaults element placed directly under the test plan applies to samplers in every thread group. One placed under a thread group applies to that group only. One placed under a logic controller applies only to the samplers inside that controller. The closer the element is to a sampler, the narrower and more specific its reach.

flowchart TD
    TP["Test Plan"] --> D0["HTTP Request Defaults: global"]
    TP --> TG1["Thread Group: shoppers"]
    TP --> TG2["Thread Group: admins"]
    TG1 --> D1["HTTP Request Defaults: shop host"]
    TG1 --> S1["Sampler: browse"]
    TG1 --> SC["Simple Controller: reports"]
    SC --> D2["HTTP Request Defaults: reporting host"]
    SC --> S2["Sampler: monthly report"]
    TG2 --> S3["Sampler: admin dashboard"]
        

When several defaults elements overlap

When more than one defaults element applies to the same sampler, the nearest one in the tree takes priority over those placed higher up, and fields left blank in the nearer element can still be filled from the outer one. At the very same level, two elements can compete in a way that depends on their order, which is hard to reason about. The safest design is to keep one defaults element per scope and avoid duplicates at the same level.

The defaults element is the natural control point for pointing one script at many targets.

Because the host, protocol and port live in one place, that place is also the natural spot to connect the plan to the outside world. Instead of typing a fixed host, the field can read a value that is supplied from elsewhere: a variable defined in the plan, or a property given at launch time. Changing the target then requires no edit to the script file at all.

flowchart LR
    CI["Pipeline or command line supplies environment values"] --> P["JMeter properties"]
    P --> D["HTTP Request Defaults fields read the values"]
    D --> R["All requests go to the chosen environment"]
    R --> T1["Development"]
    R --> T2["Testing"]
    R --> T3["Staging"]
        

Variables versus properties

Variables belong to a running thread or to the plan and are set inside the test, often by a user-defined variables element. Properties belong to the whole JMeter process and can be supplied when the tool is launched. For switching environments in an automated pipeline, properties are the better fit, because the pipeline can pass them without touching the file. A sensible default value for each property should be provided, so the plan still runs when nothing is supplied.

A single source of truth

The benefit of this design is that the environment is described in exactly one spot. Reviewers can see the target at a glance, automation can override it cleanly, and nobody has to wonder whether a request in the middle of the plan still points at an old server.

Small differences here change both the load on the server and the cost on the load generator.

Choosing between plain and secure transport is not cosmetic. Secure connections require a handshake in which the two sides agree on encryption, and that handshake uses processor time on both the server and the load generator. A test against a plain endpoint can look dramatically faster than the same test against the secure production endpoint, simply because the handshake work is missing. To get results that predict production, test the same transport that real users use.

Ports deserve similar care. Applications behind load balancers often listen on one port externally and another internally. If the test goes directly to an internal port, it bypasses the load balancer, the firewall and the secure termination point, and the measured capacity describes a path real users never take. Decide deliberately which entry point the test should exercise, and write that decision in the plan documentation.

Connection reuse and its effect

Real browsers keep connections open and reuse them across several requests, which saves repeated handshakes. How a test client behaves here changes the load profile, since a client that reconnects every time puts far more handshake pressure on the server than one that reuses connections. When comparing results between runs or tools, keep the connection behaviour identical, otherwise differences may come from the client and not from the application.

A single defaults element fits one main host; other hosts need a plan.

Modern applications rarely live on one host. A web front end may call an API gateway, an authentication service, an image server and external payment or analytics providers. A single defaults element can only supply one host at a time per scope, so a design for multiple hosts needs thought. The goal is to keep the main host centralised while giving the exceptions a clean, visible home.

flowchart TD
    A["Request targets which host?"] --> B{"Is it the main application host?"}
    B -- "Yes" --> C["Leave host blank and inherit from global defaults"]
    B -- "No" --> D{"Several requests to the same other host?"}
    D -- "Yes" --> E["Group them under a controller with its own defaults"]
    D -- "No" --> F["Fill the host and any other differing fields on that sampler"]
        

Three workable strategies

One tick box in the defaults can change the volume of traffic dramatically.

When a browser loads a page, the page itself is only the beginning. It then downloads stylesheets, scripts, images and fonts that the page refers to. JMeter can imitate this by retrieving all embedded resources after fetching a page. Enabling this in the defaults means every page request in scope automatically does so, which makes the test far closer to a real browser experience but also far heavier.

Parallel downloads

Real browsers fetch several resources at once over multiple connections. JMeter offers a parallel download option with a pool size, commonly set to a small number that mimics browser behaviour. Without parallelism, resources are fetched one after another, which makes page load times look much longer than any browser would show. With parallelism enabled, each thread opens several connections at the same moment, so the load on the server and the demand on the injector rise accordingly.

Filtering with URL patterns

Two pattern fields let you decide which resources are fetched. One lists patterns that must match, restricting downloads to chosen hosts. The other lists patterns that must not match, excluding unwanted ones. The usual use is to keep downloads on your own domains and to exclude third-party scripts such as analytics, advertising and social widgets, which you must not load test and which add noise.

Two timeout fields decide how long a request may wait before it is declared failed.

The connect timeout limits how long the client waits to establish a connection. The response timeout limits how long it waits for the server to respond once connected. When left empty, the client may wait for a very long time, which means a hung server can freeze threads indefinitely and distort the whole test. Setting both in the defaults protects every request at once.

Choosing values is a design decision. A timeout that is too short turns slow-but-valid responses into failures, which makes the error rate look worse than the real user experience. A timeout that is too long hides outages, because threads sit waiting instead of reporting a problem. A good approach is to base timeouts on the service’s agreed limits, giving some margin above the slowest acceptable response.

The choice of implementation

JMeter can send requests through more than one underlying HTTP client library. The default modern implementation supports the widest set of features, including connection reuse and richer configuration, while the older Java-based one has fewer capabilities. Mixing implementations across samplers in the same test makes behaviour inconsistent. Set the implementation once in the defaults, and let every request share it.

Advanced network options that matter in corporate and multi-address environments.

Some organisations require outbound traffic to pass through a proxy server. The defaults element lets you configure the proxy once, with its host, port and optional credentials, so every request travels the same route. This is important for realism if real users also pass through such a proxy, but it is equally important to remember that the proxy itself becomes part of the measured path and can become the bottleneck.

The source address setting chooses the local network address from which requests are sent. On a load generator with several addresses, this lets you control which network interface the traffic uses. It is also used to spread connections across several addresses to avoid exhausting the limited supply of local ports when very large numbers of connections are opened to a single destination.

The least-used fields are the ones most likely to cause confusion.

The defaults element offers a path field, but a default path is rarely useful, because almost every request in a real plan names its own path. Setting a default path can even cause harm, since a sampler that accidentally leaves its path blank will silently hit the default instead of failing loudly. For most plans it is better to leave the default path empty so that a missing path shows up as an obvious error.

The element also accepts parameters and body data. These are meant for values that should accompany every request, but they behave in ways that surprise people, particularly when a sampler defines its own parameters. Because the exact merging behaviour is easy to misjudge, verify it by examining the actual request in the results viewer rather than assuming. For values that must be sent on every request, such as an API version or a tracking token, a header manager is often the clearer choice.

Content encoding

The content encoding field decides which character set is used to encode parameter values before sending them. Using a universal text encoding avoids corrupted characters when test data includes accents, currency symbols or non-Latin scripts. Setting it once in the defaults ensures all requests encode data the same way, which keeps test data behaviour consistent with what real browsers send.

Defaults work best alongside a small set of companion elements.

HTTP Request Defaults handles where requests go and a few shared settings. Other config elements handle different shared concerns, such as headers, cookies, caching and data. Together they describe how a realistic client behaves. Knowing what each one owns prevents the temptation to cram everything into the defaults.

The Cookie and Cache pairing

Two partners deserve special mention. A cookie manager gives each virtual user its own session, so that logins and shopping baskets behave properly. A cache manager makes repeated downloads of unchanged resources behave like a browser instead of re-downloading everything every time. When embedded resources are enabled in the defaults, adding a cache manager is usually essential for realism, because real users do not fetch the same logo on every page.

Recorded scripts are full of repetition that the defaults element can remove.

The HTTP test script recorder captures real browser sessions and turns them into samplers. Recorded samplers usually arrive with the full host, protocol and port repeated on every single row, because the recorder wrote down exactly what the browser did. The recorder can create a defaults element and strip repeated values from samplers automatically, depending on its options, which gives you a cleaner plan from the start.

When many machines or pipelines run the plan, the source of each value matters.

In a distributed test, a controller machine sends the plan to several injectors, and each injector runs it independently. Values typed into the plan travel with it, so every injector sees the same defaults. Values supplied as properties, however, must be present on each injector, or the injector falls back to a default value that may differ from what the controller used. Mismatched properties are a quiet cause of injectors testing the wrong environment.

sequenceDiagram
    participant P as Pipeline
    participant C as Controller
    participant I1 as Injector 1
    participant I2 as Injector 2
    participant T as Target Environment
    P->>C: Start test with environment properties
    C->>I1: Send plan and properties
    C->>I2: Send plan and properties
    I1->>T: Requests resolved from defaults
    I2->>T: Requests resolved from defaults
    Note over I1,I2: Confirm both injectors received identical values
        

Practical safeguards

Never assume the defaults did what you expected; look at the evidence.

Because inheritance happens silently, debugging means checking the final resolved request. The results viewer shows the exact address, the headers sent and the response received for each sample. Inspecting a handful of requests in a single-user run confirms whether each one resolved to the intended host, protocol and port, and whether any request quietly used a leftover override.

Symptoms and likely causes

Settings in the defaults change what the numbers mean.

Defaults do not just route traffic; they change what each reported number represents. Enabling embedded resources multiplies the number of samples, so throughput expressed in requests per second now includes images and scripts. Response time per page may be reported as a separate page sample or as many individual resource samples, depending on how you group them. Comparing two runs with different resource settings is meaningless unless you account for that difference.

Keeping runs comparable

For fair comparisons between builds or environments, freeze every setting in the defaults, including timeouts, resource handling and implementation, and record them with the results. If any of them change between runs, document the change and treat the runs as different experiments. The most trusted performance reports state their configuration in a short header so readers know exactly what was measured.

The defaults element decides which system receives your load, so treat it as a safety control.

Because one value can redirect an entire test, a mistake in the defaults can send heavy load to a system that was never meant to receive it, such as a live production service or a third-party provider. Governance around this single element is therefore an inexpensive and effective safeguard. Reviewers should check the target before every significant run, just as a pilot checks the destination before takeoff.

Habits that keep the element helpful instead of hazardous.

The same element solves very different problems.

It supplies fallback values such as host, protocol, port, timeouts and resource handling to HTTP requests whose own fields are blank, so shared settings are declared in one place.

Yes. A value typed on the sampler always wins, and a blank sampler field falls back to the defaults. Each field is resolved independently.

Place a single element at plan level for settings shared by all groups. Add narrower ones under thread groups or controllers only when a branch targets a different host.

One element supplies one host per scope. Keep the main host in the defaults and give exceptions their own values, a controller with local defaults, or named values chosen per sampler.

Make the host, protocol and port fields read values supplied from properties or variables, with safe fallbacks. A pipeline can then change the target at launch time.

A common cause is inheritance: a sampler overrode the host but left the port blank, so it inherited a port meant for a different host. Fill the port on that sampler.

Only for page-level tests that need to behave like a browser. Leave it off for API and server-focused tests, and add filters and a cache manager when it is on.

Base it on the service’s agreed limits plus a margin. Too short creates false failures and too long hides outages. Override per request for known slow operations.

Generally no. A default path lets a request with a forgotten path silently hit the wrong page. Keep paths on the samplers so mistakes fail loudly.

Run a single user and inspect the requests in the results viewer to see the resolved address, headers and response for each sample.

Yes. Values in the plan travel to every injector. Properties must be present on each injector, otherwise an injector may fall back to a different value than the controller used.

Most likely embedded resources were switched on, so images, scripts and stylesheets now count as separate samples. Compare runs only when this setting matches.

HTTP Request Defaults looks like a small convenience, yet it is the control point for where a test sends its load, how long requests may wait, whether pages behave like browsers and how easily a script moves between environments. Used with discipline, it makes plans shorter, safer and portable. Used carelessly, it hides stale hosts, inflates sample counts and sends load to the wrong place. Treat it as a declared, reviewed and verified part of every test plan.