URL encoder
Percent-encoding (URL encoding) makes arbitrary text safe to place inside a
URL by replacing reserved and non-ASCII characters with a % followed by two
hexadecimal digits. A space becomes %20, an ampersand %26, and the accented
é becomes %C3%A9. This encoder applies that transformation so you can build
query strings, share links, or pass values to an API without them breaking the URL
— all in your browser.
When to use component mode vs. full-URL mode
The right mode depends on what you are encoding:
Component mode (encodeURIComponent) — use this for individual values going into a URL: a search query, a redirect target, an address in a parameter. It escapes everything that could be misread as URL structure, including & = ? : / # +. For example, if a user enters a city name “New York & London” and you want it in ?city=New+York+%26+London, apply encodeURIComponent to the value before appending.
Full-URL mode (encodeURI) — use this when you have a complete URL that is already properly structured but contains non-ASCII characters or unencoded spaces. It leaves the structural characters (? & = # / : @) untouched so the URL remains valid, but encodes spaces and accented letters. Appropriate when you need to make a well-formed URL safe for display or transport without changing its structure.
The encoding rules, mode by mode
The tool uses the browser’s two built-in encoding functions:
- Component mode —
encodeURIComponenttreats the input as a single value and escapes the URL reserved characters too (: / ? & = # +and more). Use it for one query value or path segment. - Full-URL mode —
encodeURIescapes spaces and non-ASCII characters but leaves reserved separators intact, so a complete URL stays usable.
Both encode non-ASCII characters as their UTF-8 byte sequences, and both leave
the unreserved set (A–Z a–z 0–9 - _ . ! ~ * ' ( )) untouched.
Character encoding reference
| Character | Component mode | Full-URL mode | Notes |
|---|---|---|---|
| (space) | %20 | %20 | Never encodes as + (that is form encoding) |
| & | %26 | kept | Separates params — must encode in values |
| = | %3D | kept | Key-value separator — must encode in values |
| ? | %3F | kept | Starts query string |
| / | %2F | kept | Path separator |
| # | %23 | kept | Fragment identifier |
| é | %C3%A9 | %C3%A9 | UTF-8 bytes: 0xC3 0xA9 |
| 中 | %E4%B8%AD | %E4%B8%AD | Three UTF-8 bytes |
Worked example
The value John & Jane? encoded in component mode becomes John%20%26%20Jane%3F:
the spaces are %20, the ampersand %26, and the question mark %3F. In full-URL
mode the same text becomes John%20&%20Jane? — the & and ? survive because
they are structural URL characters.
Note: a space is always %20 here, not +. The + convention belongs to HTML form (application/x-www-form-urlencoded) encoding, which is a different spec. Standard URI encoding always uses %20 for spaces.
Everything runs in your browser with built-in functions — nothing is uploaded. To reverse it, use the URL decoder.
The space problem: %20 or +?
Two different standards answer “how do I encode a space” differently, and
mixing them is the most common URL-encoding bug. In a URI proper, a space
is percent-encoded as %20, per
RFC 3986. But in HTML form
submissions (application/x-www-form-urlencoded, as processed by the
WHATWG URL Standard), spaces historically
become +. A server decoding form data will turn + into a space — so a
literal plus sign in form data must itself be encoded as %2B. When you
control both ends, standardise on %20 everywhere; when consuming form
data, remember the + rule before declaring the data corrupted.
Double encoding: the bug that hides in redirects
Encoding an already-encoded string turns %20 into %2520 (the % itself
becomes %25), producing URLs that decode to garbage one layer too early
or too late. It creeps in wherever a URL passes through multiple systems —
a redirect parameter carrying a return URL, an analytics wrapper, a proxy —
each “helpfully” encoding again. The discipline that prevents it: encode
exactly once, at the moment a raw value is inserted into a URL, and decode
exactly once, at the moment it is extracted. If you receive a value
containing %25, inspect whether it is a genuine percent literal or
evidence that an upstream system encoded twice.
As a rule of thumb for auditing existing URLs: seeing %25 means something
was double-encoded, seeing a bare % followed by non-hex characters means
something was never encoded, and seeing + outside a query string means
form-encoding leaked into a path — three one-glance diagnoses that cover
most encoding bugs in the wild.