In REST Assured, what changes when you set given().urlEncodingEnabled(false) on a request?

middlemust knowfreq 44%

answer

a request-wide switch, not per value
default is on
exists to prevent double encoding
reset() restores the static default

basics

~20 s

Setting urlEncodingEnabled(false) switches REST Assured's automatic URL encoding off for that whole request, path placeholder values included. Whatever you supply then goes on the wire as typed, so you become responsible for encoding every value yourself. The default is on.

solid answer

~50 s

urlEncodingEnabled is a switch, not a per-value setting. given().urlEncodingEnabled(false) — or the static RestAssured.urlEncodingEnabled = false, which RestAssured.reset() puts back — turns REST Assured's percent-encoding off for the entire request: the path it builds from your placeholders and the parameters alike. The reason it exists is double encoding. If the value you hold is already escaped, the default behaviour escapes its % signs in turn, so MOROCCO%2FRED leaves as MOROCCO%252FRED and the server matches nothing. With encoding off it arrives untouched. The cost is that the switch is all-or-nothing per request: every other value on that call must now be pre-encoded by hand, and one stray space produces a malformed URL. Reach for it only when the value genuinely arrives pre-encoded; fixing the value, or splitting a structured identifier across two placeholders, is almost always the smaller change.

`urlEncodingEnabled` is a switch, not a per-value setting. `given().urlEncodingEnabled(false)` — or the static `RestAssured.urlEncodingEnabled = false`, which `RestAssured.reset()` puts back — turns REST Assured's percent-encoding off for the entire request: the path it builds from your placeholders and the parameters alike. The reason it exists is **double encoding**. If the value you hold is already escaped, the default behaviour escapes its `%` signs in turn, so `MOROCCO%2FRED` leaves as `MOROCCO%252FRED` and the server matches nothing. With encoding off it arrives untouched. The cost is that the switch is all-or-nothing per request: every other value on that call must now be pre-encoded by hand, and one stray space produces a malformed URL. Reach for it only when the value genuinely arrives pre-encoded; fixing the value, or splitting a structured identifier across two placeholders, is almost always the smaller change.

code

java · 16 lines

java

import io.restassured.RestAssured;
import static io.restassured.RestAssured.given;

// The code already carries a percent-escape; escaping it again
// would send MOROCCO%252FRED and match nothing
given()
    .urlEncodingEnabled(false)
    .pathParam("clothCode", "MOROCCO%2FRED")
.when()
    .get("/cloths/{clothCode}")
.then()
    .statusCode(200);

// The same switch as a static - reset() puts it back to true
RestAssured.urlEncodingEnabled = false;
RestAssured.reset();

go deeper

for a junior

Know that the default is on and that you should not hand REST Assured a pre-escaped value. If you meet urlEncodingEnabled(false) in a test, be able to say what it turns off.

for a middle

Explain double encoding concretely, including what %25 in a URI means, and name both places the switch lives: the request specification and the static field restored by reset().

for a senior

Weigh the blast radius. Show why a request-wide switch is risky in shared setup, how a leaked static causes order-dependent failures, and which fixes you would try before disabling encoding.

for a principal

Own the guidance. Decide whether the static form is banned outright in the suite, and how tests obtain already-encoded identifiers so that switching encoding off is never the routine answer.

What the switch actually controls

urlEncodingEnabled decides whether REST Assured percent-encodes the URL it builds. It is true out of the box — the constant RestAssured.DEFAULT_URL_ENCODING_ENABLED is true — and when it is on, every path segment produced from a placeholder, along with the parameters appended to the URL, is escaped for you. Turning it off does not narrow the encoding to a particular value or a particular placeholder; it removes the escaping step from that request entirely, and whatever you supply is written into the URL exactly as you typed it.

There are two places to set it:

given().urlEncodingEnabled(false) on RequestSpecification, scoped to the one request you are building.
RestAssured.urlEncodingEnabled = false as a static, which affects every request built afterwards until RestAssured.reset() restores the default.

The problem it exists to solve

The switch is there for values that are already encoded by the time your test gets them: an id copied out of a previous response, a signed link, a query string assembled by another system. Escaping such a value again escapes its percent signs, which is silent and total:

encoding	value you pass	what the server receives
on (default)	`MOROCCO/RED`	`MOROCCO%2FRED` — correct
on (default)	`MOROCCO%2FRED`	`MOROCCO%252FRED` — double-escaped
off	`MOROCCO%2FRED`	`MOROCCO%2FRED` — correct
off	`MOROCCO/RED`	`MOROCCO/RED` — an extra path segment

The second row is the failure people actually hit. Nothing throws; the request goes out, and the bindery API answers 404 for a cloth code that plainly exists. The last row is the mirror image and is just as easy to cause once the switch is off.

The cost of turning it off

Because the switch is per request rather than per value, the burden it hands you is wider than the one value you were trying to fix:

Every path placeholder value on that request must now be correct URL text, including ones a colleague adds later.
A space, an ampersand or a brace in any of those values will now travel raw and can produce a malformed or misparsed request line.
The same call's parameters lose their escaping too, so a value that was fine yesterday can break when someone appends a filter to the request.
Set statically, the change leaks into every test that runs after it in the same JVM unless something resets it, which makes ordering-dependent failures that are miserable to bisect.

When to reach for it, and what to try first

Fix the value. If you are pre-escaping something before handing it to pathParam, stop — the default behaviour already does that job, and removing your escaping is a smaller change than disabling the library's.
Fix the template. If a value contains a separator because the identifier really has structure, split it into two placeholders so the structure lives in the path rather than in the value.
Then, if the value is genuinely opaque and already encoded, disable encoding for that one request and keep the scope as tight as you can — the instance call, not the static field.
If you must use the static, restore it immediately afterwards. RestAssured.reset() returns urlEncodingEnabled to its default along with the other statics it clears.

Diagnosing a suspected encoding problem

The fastest confirmation is to look at what was actually sent rather than reasoning about it. given().log().uri() is on the request half of the log DSL and prints the fully built request URI, placeholders resolved and escaping applied. Three signatures are worth recognising at a glance:

%25 anywhere in the path almost always means a value was escaped twice.
A raw /, space or & in a segment means encoding was disabled somewhere upstream, possibly by a static left over from another test.
A + where a space belongs means the text came from somewhere other than REST Assured's own path handling, since it rewrites that + to %20.

Read as a whole, the design is deliberately blunt: REST Assured assumes you want correct URLs and will build them, and the only way to override that is to take the whole job back for a request. Treat the switch as the exception it is, and prefer changing the value or the template whenever you have that option.

## What the switch actually controls `urlEncodingEnabled` decides whether REST Assured percent-encodes the URL it builds. It is `true` out of the box — the constant `RestAssured.DEFAULT_URL_ENCODING_ENABLED` is `true` — and when it is on, every path segment produced from a placeholder, along with the parameters appended to the URL, is escaped for you. Turning it off does not narrow the encoding to a particular value or a particular placeholder; it removes the escaping step from that request entirely, and whatever you supply is written into the URL exactly as you typed it. There are two places to set it: - `given().urlEncodingEnabled(false)` on `RequestSpecification`, scoped to the one request you are building. - `RestAssured.urlEncodingEnabled = false` as a static, which affects every request built afterwards until `RestAssured.reset()` restores the default. ## The problem it exists to solve The switch is there for values that are **already encoded** by the time your test gets them: an id copied out of a previous response, a signed link, a query string assembled by another system. Escaping such a value again escapes its percent signs, which is silent and total: | encoding | value you pass | what the server receives | |---|---|---| | on (default) | `MOROCCO/RED` | `MOROCCO%2FRED` — correct | | on (default) | `MOROCCO%2FRED` | `MOROCCO%252FRED` — double-escaped | | off | `MOROCCO%2FRED` | `MOROCCO%2FRED` — correct | | off | `MOROCCO/RED` | `MOROCCO/RED` — an extra path segment | The second row is the failure people actually hit. Nothing throws; the request goes out, and the bindery API answers 404 for a cloth code that plainly exists. The last row is the mirror image and is just as easy to cause once the switch is off. ## The cost of turning it off Because the switch is per request rather than per value, the burden it hands you is wider than the one value you were trying to fix: - Every path placeholder value on that request must now be correct URL text, including ones a colleague adds later. - A space, an ampersand or a brace in any of those values will now travel raw and can produce a malformed or misparsed request line. - The same call's parameters lose their escaping too, so a value that was fine yesterday can break when someone appends a filter to the request. - Set statically, the change leaks into every test that runs after it in the same JVM unless something resets it, which makes ordering-dependent failures that are miserable to bisect. ## When to reach for it, and what to try first 1. **Fix the value.** If you are pre-escaping something before handing it to `pathParam`, stop — the default behaviour already does that job, and removing your escaping is a smaller change than disabling the library's. 2. **Fix the template.** If a value contains a separator because the identifier really has structure, split it into two placeholders so the structure lives in the path rather than in the value. 3. **Then, if the value is genuinely opaque and already encoded**, disable encoding for that one request and keep the scope as tight as you can — the instance call, not the static field. 4. **If you must use the static**, restore it immediately afterwards. `RestAssured.reset()` returns `urlEncodingEnabled` to its default along with the other statics it clears. ## Diagnosing a suspected encoding problem The fastest confirmation is to look at what was actually sent rather than reasoning about it. `given().log().uri()` is on the request half of the log DSL and prints the fully built request URI, placeholders resolved and escaping applied. Three signatures are worth recognising at a glance: - `%25` anywhere in the path almost always means a value was escaped twice. - A raw `/`, space or `&` in a segment means encoding was disabled somewhere upstream, possibly by a static left over from another test. - A `+` where a space belongs means the text came from somewhere other than REST Assured's own path handling, since it rewrites that `+` to `%20`. Read as a whole, the design is deliberately blunt: REST Assured assumes you want correct URLs and will build them, and the only way to override that is to take the whole job back for a request. Treat the switch as the exception it is, and prefer changing the value or the template whenever you have that option.

How would you scope the static form so it cannot leak into unrelated tests?
Wrap it: set `RestAssured.urlEncodingEnabled = false` in a try block and call `RestAssured.reset()` in the finally, or set it in a per-test setup with a matching teardown. Better still, prefer `given().urlEncodingEnabled(false)`, which cannot leak at all because it lives on the one request specification you are building.
You see %252F in a logged request URI. What does that tell you?
That the value was escaped twice: `%25` is the escape for a percent sign, so a `%2F` that was already in the value has been encoded again. Either the test pre-escaped a value while encoding was on, or the value arrived pre-escaped from an earlier response. Remove the pre-escaping, or disable encoding for that request.

saying these in an interview costs you the question

Thinks the switch applies to one value rather than the whole request
Uses it to force a raw slash into a path segment
Sets the static and never resets it
Believes disabling encoding also affects the response
Assumes pre-escaping a value is safe while encoding is on

In REST Assured, what changes when you set given().urlEncodingEnabled(false) on a request?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the switch actually controls

The problem it exists to solve

The cost of turning it off

When to reach for it, and what to try first

Diagnosing a suspected encoding problem

▾common follow-ups2 questions

▾red flags5 flags

What the switch actually controls

The problem it exists to solve

The cost of turning it off

When to reach for it, and what to try first

Diagnosing a suspected encoding problem

answer

go deeper