Encode a URL path while preserving slashes. Each segment between slashes is encoded independently, so structural / stays as / while spaces and special chars in segment names get percent-encoded.
The path is the part of a URL after the host — a hierarchical route to a resource, with segments separated by /. Encoding it correctly means a context-aware job: the structural slashes must stay literal so routing works, while the content inside each segment gets percent-encoded. That’s what this tool does, and it’s why a generic encoder is the wrong choice for a path (more on that below).
RFC 3986 sorts the characters that can appear in a path into classes, each with its own encoding rule:
| Character class | Characters | Path encoding rule | Example |
|---|---|---|---|
| Reserved separator | / |
Stays literal — it’s the segment separator. Encoding it to %2F can make a reverse proxy return 404 |
/api/v2/products/ |
| Unreserved | A–Z a–z 0–9 - _ . ~ |
Always left untouched — universally safe in a path, never need encoding | secure-slug_v2 |
| Space | (blank space) | Becomes %20 — not +. In a path, a literal + is a plus sign, not a space |
/items/new%20product |
| Sub-delimiters | ; , = ! $ & ' ( ) * + |
Allowed literal in a segment; a slash-aware encoder preserves them to support matrix parameters | /cars;color=red/models |
| Multi-byte | Accents, emoji, Cyrillic, … | Encoded as raw UTF-8 bytes, each byte percent-encoded independently | %F0%9F%93%A5 |
A note on the sub-delimiter row: the slash / is a reserved general delimiter, not a sub-delimiter — that’s why it’s in its own class above. The sub-delimiters (; , = and friends) are what make matrix parameters like ;color=red work inside a single segment.
JavaScript’s encodeURIComponent() treats the slash as a character to escape, so running a whole path through it turns /api/users/profile into api%2Fusers%2Fprofile. Reverse proxies and servers — Nginx, Apache, AWS API Gateway — route on literal slashes; hand them an encoded one and they can reject the request with a 400 or 404, or normalize it in surprising ways. The slash-aware approach is to split the path at the slashes and encode each segment separately, so /api/users/john doe becomes /api/users/john%20doe — segment contents encoded, structure intact. That’s exactly what this tool does; use a component encoder only on a single segment, never on the whole path.
This one isn’t an encoding rule — both hyphen and underscore are unreserved and never encoded — but it affects how search engines read your paths. Google treats a hyphen as a word separator and an underscore as a word joiner: /blue-shoes is read as two words (“blue” and “shoes”), while /blue_shoes can be read as the single token blueshoes. For clean keyword extraction, prefer hyphens in slugs.
See also: How to escape a forward slash in a URL path — a step-by-step guide with runnable code.
See also: How to prevent directory traversal attacks — a step-by-step guide with runnable code.
Honest scope: RFC 3986 defines which characters are legal where in a path. Whether an encoded slash (%2F) is accepted or rejected is a server-configuration matter — behaviour varies across Nginx, Apache, and cloud gateways — so test against your own stack. The hyphen-vs-underscore point is an SEO convention, not an encoding rule.
It encodes the segments of a URL path while leaving the structural slashes intact, so / stays as / but spaces and special characters inside each segment get percent-encoded. That keeps routing working while making the path valid.
In a path, / is a structural separator between directories, so it must stay literal. In form data a slash is just a value, so it’s encoded to %2F. This tool preserves path slashes; encode a segment separately if it contains a literal slash you want escaped.
If a resource identifier contains a special character — say an email with a ?, or a name with a space — it must be encoded so the router reads it as one path segment rather than the start of a query. Otherwise the route breaks or hits the wrong handler.
It reads each character’s UTF-8 bytes and percent-encodes them, so an accented segment becomes valid hex while still decoding back to the original text on the server.
Path segments need strict encoding because they drive server-side routing. The fragment (after #) is client-side only and allows a looser character set, so it’s encoded less aggressively.
Some servers reject or normalize an encoded slash in the path as a defense against path-traversal tricks, so a legitimately encoded %2F in your data can 404. Where possible, pass such values as query parameters instead.
Both are unreserved characters under RFC 3986 (A–Z a–z 0–9 - _ . ~), meaning they’re always safe in a URL and never need encoding.
Google treats a hyphen as a word separator but an underscore as a word joiner, so red-shoes reads as two words while red_shoes can read as one token. Hyphens make keyword extraction cleaner — a routing detail, not an encoding one.
Matrix parameters attach attributes to a specific path segment using semicolons (/cars;color=red/models). A path encoder must leave those semicolons intact while still escaping other special characters in the segment.
Yes — strict gateways reject invalid or dangerous path characters outright to guard against injection and traversal. Encoding the segment properly is what keeps the request well-formed.
Subdomains are limited to a narrow alphanumeric-plus-hyphen set and can’t carry arbitrary percent-encoded values; internationalized names use Punycode instead. Path segments accept a much wider range of encoded characters.
Yes — all encoding happens in your browser, so nothing you enter is sent anywhere, and it works offline.
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.