URL encoder and decoder online
Percent-encode a value for a query string, or decode a URL full of %20 and %3A back into something readable.
Runs entirely in your browser. Your URLs are never uploaded.
Component mode encodes everything unsafe, including / ? & and =. Use it for a single value that goes inside a query string.
How to use the URL encoder and decoder
- Paste your URL or value into the box. Either a complete address or a single parameter value works.
- Pick a mode. Component is for one value going inside a URL. Full URL is for an entire address where the slashes and question mark must survive.
- Press Encode or Decode. If you paste a full URL, the query parameters are also broken out into a readable table underneath so you can see what each one carries.
- Copy the result. Decoding is safe to run on anything — if the input was not encoded, you get it back unchanged.
What you can use it for
Building tracking links by hand is where most people meet percent-encoding. A UTM campaign name with spaces in it will break the moment someone pastes the link into a platform that stops reading at the space. Encoding the value first makes the link survive email clients, chat apps and analytics tools intact.
Debugging a redirect that carries another URL inside it needs component mode specifically. When ?return=https://site.com/page is not encoded, everything after the first & belongs to the outer URL rather than the inner one, and the redirect lands somewhere unexpected. Encoding the inner URL as a component fixes it.
Reading a URL from a log file or an analytics report is the decode direction. A referrer full of %3A%2F%2F and %20 is unreadable until you decode it, and once decoded the search query or campaign that produced the visit is usually plain to see.
Non-English URLs need it constantly. A path or query containing Hindi, Tamil or Arabic characters must be percent-encoded to travel over HTTP, which is why such links look like long strings of %E0%A4 when copied out of a browser address bar.
Component versus full URL
Component mode is the JavaScript encodeURIComponent function. It encodes every character that is not a letter, digit, or one of - _ . ! ~ * ' ( ). That includes the structural characters : / ? # [ ] @ $ & + , = which is exactly what you want when the text is a value rather than part of the URL's structure.
Full URL mode is encodeURI. It leaves the structural characters alone so that https:// stays https:// and ?a=1&b=2 keeps working, and only encodes genuinely unsafe things such as spaces and non-ASCII letters. Use it to clean up a whole address, never to encode a single parameter value.
Getting this backwards is the most common URL bug there is. Encode a full URL with component mode and every slash becomes %2F, producing a link that goes nowhere. Encode a parameter value with full URL mode and any & inside it will still be read as a separator, silently truncating the value.
A space becomes %20 in a path and may appear as + in a query string, because HTML form submissions historically used + for spaces. Both decode back to a space in a query string, but + in a path is a literal plus sign. This is a genuine inconsistency in the standards rather than a bug in any particular tool.
Frequently asked questions
encodeURI is for a whole address and preserves the characters that give a URL its structure. encodeURIComponent is for one piece of data going into that address and encodes those characters too. Rule of thumb: if what you are encoding is a value that came from a form, a search box or a database, use component mode.
Those are encoded spaces. A URL cannot contain a literal space, so any filename or search term with spaces gets them replaced with %20. Decoding here turns them back into readable text. If you control the URLs, using hyphens instead of spaces avoids the problem entirely.
Yes, and it is a frequent bug. Encoding an already-encoded string turns each % into %25, so %20 becomes %2520. The link then decodes to %20 rather than a space and fails. Decode first to check what state a string is actually in before encoding it.
No. A properly formed URL is already valid in an href. Only encode the individual values you are inserting into it. Encoding the whole thing breaks the structure that makes it a link at all.