URL Encoder

Percent-encode text and URLs — component or full-URL mode.

Free URL encoder that percent-encodes text for query strings or whole URLs, using encodeURIComponent or encodeURI. Runs entirely in your browser — nothing is uploaded. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is the difference between the two modes?

Component mode (encodeURIComponent) escapes everything including : / ? & #, which is what you want for a single query value. Full-URL mode (encodeURI) preserves those reserved characters so a complete URL stays usable.

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 — encodeURIComponent treats 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 — encodeURI escapes 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

CharacterComponent modeFull-URL modeNotes
(space)%20%20Never encodes as + (that is form encoding)
&%26keptSeparates params — must encode in values
=%3DkeptKey-value separator — must encode in values
?%3FkeptStarts query string
/%2FkeptPath separator
#%23keptFragment identifier
é%C3%A9%C3%A9UTF-8 bytes: 0xC3 0xA9
%E4%B8%AD%E4%B8%ADThree 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.