URLs only permit a limited set of characters. Drop a space, a non-Latin character, an &, a ? or a # straight into an address and the structure breaks or your value gets truncated. Percent-encoding rewrites those characters as safe %XX sequences, and this tool converts in both directions.
Offering three distinct encoding modes matters more than it sounds. The same string needs a different escaping range depending on whether it is one query value, a whole URL, or an HTML form submission. Reaching for the wrong function is how parameters silently vanish and how an & inside a value gets mistaken for a separator.
How to use
- Choose direction and mode — Pick encode or decode, then one of the three modes below. The explanation under the control changes with your selection, so you can confirm the mode fits your situation before relying on it.
- Check the result and its size — Output appears immediately with a byte count and the change against the input. Non-Latin characters are three bytes each in UTF-8 and become nine once percent-encoded, so a phrase can triple in length — worth knowing before you hit a URL length limit.
- Break a URL into parts — Paste a full address and it is split into protocol, host, port, path, query and fragment. Handy when you cannot tell where the path ends and the query begins, or want to confirm a port survived.
- Edit query parameters directly — A URL with a query string expands into an editable key/value table. Change values, add rows or delete them and a rebuilt URL appears below, ready to copy. This is the fastest way to strip a pile of tracking parameters off a link.
Frequently asked questions
What is the difference between encodeURI and encodeURIComponent?
How much they escape. encodeURIComponent (component mode) escapes /, ?, &, = and # as well; encodeURI (full URL mode) treats those as structural and leaves them alone.
The working rule is simple: component for a single value, full URL for a complete address. Putting a search term into a query means ?q=${encodeURIComponent(term)} — applied to the value only. Use encodeURI there and any & inside the term is read as a parameter separator, cutting your value short.
Why is a space sometimes %20 and sometimes +?
+ means space only in application/x-www-form-urlencoded, the format browsers produce when submitting an HTML form over GET. That is why it shows up so often in query strings.
In a URL path, + is just a plus sign. Decoding it as a space there corrupts the value. This tool's form (+) mode treats + as a space while the other two leave it intact, so if a decode looks wrong, try switching modes.
I encoded an already-encoded URL.
You get double encoding, where % becomes %25 — so %20 turns into %2520 and needs decoding twice to recover.
If one decode still leaves %XX sequences behind, decode again. The root cause is almost always passing an already-encoded value back through an encoding function; the real fix is deciding explicitly, at each point in your code, whether a value is encoded or raw.
Is there a maximum URL length?
Nothing in the spec, but plenty in practice. Internet Explorer capped at 2,083 characters; modern browsers allow tens of thousands. Servers are the tighter constraint — nginx defaults to 8KB, Apache to 8,190 bytes, and CDNs and proxies each impose their own.
Staying under about 2,000 characters is safe. Note that non-Latin query values triple in length once encoded, so you reach that ceiling faster than the visible text suggests. If the payload is large, send it in a POST body instead.
Concepts worth knowing
Reserved versus unreserved characters
RFC 3986 splits URL characters in two. Unreserved characters (A-Z a-z 0-9 - . _ ~) are safe anywhere and never need escaping. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) carry structural meaning, so using one as data rather than structure requires encoding it.
A ? marks the start of a query, so a search term containing ? must become %3F or it will be read as starting a query at that point. The differences between the encoding functions come down entirely to how much of that reserved list each one touches.
How non-Latin URLs actually work
Type a Korean or Cyrillic address into the address bar and it looks native, but the request that leaves your machine carries UTF-8 percent-encoding. The address bar is simply decoding it back for display.
Domain names follow different rules entirely. Instead of percent-encoding they use Punycode, turning 한국.kr into xn--3e0b707e.kr. So the same characters are handled by two unrelated mechanisms depending on whether they sit in the domain or the path — and percent-encoding is not valid in a domain at all.
The fragment never reaches the server
Everything after # stays in the browser and is not included in the HTTP request. It was designed to scroll to a location within a document, and now also carries SPA routes and tokens in the OAuth implicit flow.
Because of that, fragments never appear in server logs — which is why analytics tools miss values after #, and why fragments are sometimes chosen deliberately to keep a value out of those logs. They do still land in browser history and can leak through referrers, so do not mistake them for a secure channel.