PercentURL / URL path separators

URL Encoder: Why %2F Can Still Return 404

When a slash belongs inside one path value, an encoder can represent it as %2F. The web server or router may still reject or decode that request before your application sees it.

Short answer: Keep real path separators as / and encode data inside each path segment. If an encoded slash then returns 404, check the server and proxy behavior before encoding it again. An encoder controls the URL string; it cannot configure how the receiving server routes that string.

The same separator-versus-data rule applies to path slashes: a slash can divide two route segments, or it can be part of one value such as an opaque file key. The correct encoding depends on which role the receiving route expects.

Two URL examples compare a slash used as a path separator with a slash encoded as data inside one path segment.
Choose whether each slash is route structure or part of the value before encoding.

Encode the value, not the route

Slash separates route segments

For a route like /docs/design review/final, the two slashes define the route. Encode each segment but join them with literal slashes:

/docs/design%20review/final

Slash is data in one segment

If one opaque identifier is the text folder/a final.pdf, encoding that whole value gives folder%2Fa%20final.pdf. Whether the server accepts it is a separate routing decision.

In JavaScript, encodeURIComponent() escapes the slash when it is inside a component:

const rawSegment = "folder/a final.pdf";
const path = "/files/" + encodeURIComponent(rawSegment);
console.log(path);
// /files/folder%2Fa%20final.pdf

In Python, urllib.parse.quote() leaves slash characters unescaped by default because its default is intended for a URL path. Pass safe="" when the entire input is one segment value:

from urllib.parse import quote

raw_segment = "folder/a final.pdf"
encoded_segment = quote(raw_segment, safe="")
print(encoded_segment)
# folder%2Fa%20final.pdf

If the slash is meant to divide route segments, split the path first, quote the individual segments, and rejoin them with /. Do not run a component encoder over the entire URL: the scheme, host, path separators, query mark, and fragment mark have different structural roles.

A request containing %2F passes through an edge, web server, and application router; each layer may preserve, reject, or decode the encoded slash.
The request passes through more than the encoder. Inspect the layer that handles the route.

Why an encoded slash can return 404

%2F is the percent-encoded form of /, but servers do not all handle it the same way. Apache HTTP Server, for example, documents AllowEncodedSlashes Off as its default: encoded path separators are refused with a 404. With On, Apache accepts and decodes them; with NoDecode, it accepts them while leaving them encoded. Apache recommends considering NoDecode when encoded slashes are needed in path info because decoding them can create unsafe paths.

A CDN, reverse proxy, web server, framework, and application router can each have their own path handling. That is why the same encoded string may work in one deployment and fail in another. Do not turn on encoded-slash support globally just to make one test URL work; first decide whether the identifier should contain a slash at all and review the receiving stack's configuration.

A quick way to locate the failing layer

  1. Confirm the value. Keep a copy of the raw identifier and the exact encoded path. A single URL-encoding pass turns its slash into %2F; changing %2F to %252F encodes the percent sign again and is not a fix.
  2. Compare a safe test route. In a test environment, compare an ordinary identifier such as folder-a with one containing an encoded slash. Do not use a production request that could change or expose real data.
  3. Read the request logs layer by layer. Check whether the request reaches the origin and whether the path is logged as %2F or as /. A response generated before the application router points to an earlier layer.
  4. Check the server's documented setting. For Apache, inspect AllowEncodedSlashes in the virtual-host/server configuration. The directive is not an .htaccess setting.
  5. Keep route validation after decoding. If an application accepts encoded path data, parse the path into components before decoding and validate the decoded value against the route's expected format.
Three checks for an encoded slash 404: confirm the raw and encoded value, inspect each server layer, and validate route behavior safely.
A small, reversible diagnostic: verify the value, find the first layer that changes it, then adjust that layer deliberately.

When a slash should not be in a path value

If your identifier is arbitrary text or can contain nested paths, consider keeping it in a query value or using an identifier format that cannot contain route delimiters. For example, a URL builder can place one value in a query parameter while preserving the outer query separators. The right representation depends on the receiving API; confirm how it parses and validates the value.

Common questions

Does encodeURIComponent() guarantee the server accepts %2F?

No. It encodes the value as a URL component. The receiving server and application decide whether encoded path separators are allowed and how they affect route matching.

Should I replace %2F with %252F if the request returns 404?

No. That adds another encoding layer to the percent sign. First inspect which layer returned the 404 and how the path was parsed.

Why does the same value work as a query parameter?

Query data and path segments have different parsing rules. A slash can be data inside a query component, while a slash in a path has a routing role. Confirm the API contract instead of moving values between components by guesswork.

References

For a general URL encoder, use the online URL encoder. For JavaScript examples, see URL encoding in JavaScript; for the broader mode comparison, see URL encode and decode.