A slash inside a path value — like a date 2026/07 or a file path used as an ID — must become %2F so it isn’t read as a path separator. But encode the whole path and you break routing. Here’s the difference, and how servers actually treat %2F.
The slash / is the path separator. When a slash is part of a value inside a segment (not structure), encode just that value with encodeURIComponent — which turns / into %2F:
const id = 'folder/report'; // a slash that's DATA, not structure
const path = '/files/' + encodeURIComponent(id);
// "/files/folder%2Freport" ← the inner slash is now %2F, one segmentNever run the whole path through encodeURIComponent — it encodes the structural slashes too and produces a broken path:
// WRONG
encodeURIComponent('/files/folder/report');
// "%2Ffiles%2Ffolder%2Freport" ← every slash gone; not a usable pathHere’s the part most guides miss. Even correctly encoded, %2F in a path is handled inconsistently by servers and proxies:
%2F in the path with a 404 or 400 by default (a security default against path-traversal tricks).%2F back into a real / before your app sees it — so your one segment silently becomes two.Because behaviour varies (Nginx, Apache, and cloud gateways each differ, and several have a specific setting for it), you must test against your own stack rather than assume.
If a value naturally contains slashes, the most portable option is to pass it as a query parameter instead of a path segment — slashes are far less fraught there:
// Instead of /files/folder%2Freport
// Prefer /files?id=folder%2Freport (or even a plain ?id=folder/report)
const url = new URL('https://api.example.com/files');
url.searchParams.set('id', 'folder/report');
// https://api.example.com/files?id=folder%2FreportWhile we’re in path territory: a space in a path segment is %20, never +. The +-means-space rule only applies to query strings. encodeURIComponent already does the right thing (space → %20).
Our path encoder is slash-aware: it encodes the contents of each segment while leaving the structural slashes intact, so you can see exactly what a safe encoded path looks like.
Written and maintained by the urlencodedecode.com team. Every technical claim on this page is verified against primary sources — the RFCs (3986, 3629, 4648, 7578), the WHATWG URL Standard, and official vendor or language documentation — rather than second-hand summaries. When a source contradicts a common assumption, we follow the source and note the discrepancy. Corrections: contactus@urlencodedecode.com.
Encode the value containing the slash with encodeURIComponent, which turns / into %2F. Encode only the individual segment or value, not the whole path — running the entire path through encodeURIComponent turns the structural slashes into %2F too and breaks routing.
Many web servers and reverse proxies reject or specially handle %2F in a path by default as a defence against path-traversal attacks. Some decode it back to a real slash before your app sees it. Behaviour varies by server, so test against your own stack or pass the value in the query string instead.
A forward slash encodes to %2F (percent sign, then the hex bytes 2F). It only needs encoding when the slash is data inside a segment; as a path separator it stays a literal /.
If the value naturally contains slashes, the query string is more portable — servers handle %2F inconsistently in the path but reliably in the query. Use ?id=folder%2Freport rather than /folder%2Freport when you can.
In a path, a space is %20. The +-means-space convention only applies to query strings (form-encoding). encodeURIComponent correctly produces %20 for a space.