URL Encoder & Decoder
Safely encode or decode URLs and query parameters — with full Unicode support.
Component mode encodes everything special — best for a single query value or parameter.
Your result will appear hereURL encoding exists because URLs were designed decades ago around a small set of safe ASCII characters, and everything else — spaces, accented letters, Arabic script, emoji, and even some punctuation — has to be smuggled through in disguise. The disguise is percent-encoding: each unsafe byte becomes a % followed by two hex digits. When it works, you never notice. When it breaks, you get the classic bugs: a search for "C++" that finds "C ", a redirect URL that dies at the first &, or a link with spaces that works in one app and breaks in another. This tool encodes and decodes both directions, entirely in your browser.
How the encoder works
Paste text or a URL into either field. The encoder converts unsafe characters into percent-encoded form; the decoder reverses it. There are two distinct modes because JavaScript offers two functions with importantly different behavior: `encodeURIComponent` encodes everything reserved, including &, =, ?, and /, which is what you want for a single parameter value; `encodeURI` leaves those structural characters alone, which is what you want for a complete URL. Choosing the wrong one is the root cause of most encoding bugs.
How percent-encoding works
Character → UTF-8 bytes → %XX for each byte
space → %20 & → %26 ? → %3F
é → %C3%A9 日 → %E6%97%A5
encodeURIComponent("a&b=c") → "a%26b%3Dc"
encodeURI("https://x.com/a b") → "https://x.com/a%20b"Non-ASCII characters are first converted to UTF-8 bytes, and each byte gets its own %XX — which is why é becomes two escapes and a CJK character becomes three. This also explains the size growth of encoded non-Latin text: an Arabic word triples in length. The + sign is a historical trap: in query strings only, an application may interpret + as a space, a convention inherited from HTML form submission. A URL with a genuine + in a parameter must encode it as %2B or some servers will silently turn it into a space.
What to know about URL encoding
- 1Use encodeURIComponent for values, encodeURI for whole URLs. Encoding a full URL with encodeURIComponent destroys its structure — the :// and every / become escapes. Encoding a parameter value with encodeURI leaves & and = unescaped, so the value bleeds into the parameter structure. This single distinction prevents most real-world bugs.
- 2Never encode twice. Encoding %20 again produces %2520, and the visible symptom is %25 appearing in URLs, or spaces displaying as %20 as literal text. Double-encoding usually happens when two layers of a system each encode defensively. Decode fully, then encode exactly once at the final boundary.
- 3The + versus %20 question depends on where you are. In the path portion of a URL, + is a literal plus and space must be %20. In query strings, many servers treat + as a space, following old form conventions. %20 is the safe choice everywhere; + is only safe if you know the server's behavior.
- 4Reserved characters are only reserved in their own position. A / in the path is structure; a / in a query value is just data and should be encoded. The same character can be legal in one part of a URL and require encoding in another — this is why generic "encode the URL" advice fails.
- 5Watch for encoding when debugging redirect chains and callbacks. OAuth flows and payment callbacks pass entire URLs as parameters of other URLs, requiring nested encoding. Each layer must be encoded once — a redirect_uri that mysteriously loses its query parameters is almost always an encoding-depth bug.
Frequently asked questions
What is the difference between encodeURI and encodeURIComponent?
encodeURIComponent escapes everything with special meaning, including &, =, ?, /, and :, making it right for encoding a single value that goes inside a URL. encodeURI preserves those structural characters, making it right for cleaning up a complete URL without destroying it. Rule of thumb: building a query parameter, use encodeURIComponent; fixing spaces in a full URL, use encodeURI.
Why do spaces sometimes appear as + and sometimes as %20?
Two different histories. Percent-encoding says space is %20. But HTML form submission, defined separately in the early web, encoded spaces as + in form data — and that convention leaked into query strings. Most servers accept both in queries; only %20 is valid in paths. When generating URLs yourself, always use %20 and encode any literal + as %2B, and you will never hit the ambiguity.
Why does my non-English text turn into so many % codes?
Because encoding operates on UTF-8 bytes, not characters. An accented Latin letter takes two bytes, so two escapes; Arabic and CJK characters take two to three bytes each; emoji take four. The URL still works — browsers decode it back — but the string is much longer. Modern browsers often display the decoded characters in the address bar while sending the encoded form on the wire.
What is double encoding and how do I fix it?
It is encoding text that was already encoded: %20 becomes %2520, because the % itself gets escaped to %25. The symptom is literal %20 or %25 appearing where a space should be. It happens when multiple layers each encode defensively. The fix is architectural: decode at the entry boundary, work with plain strings internally, and encode exactly once at the exit boundary.
Is my data sent anywhere?
No. Encoding and decoding run entirely in your browser with JavaScript — nothing is transmitted, logged, or stored. You can confirm this by disconnecting from the internet; the tool keeps working because no server is involved. This matters when you are debugging URLs that contain tokens or session identifiers.