URL Encoder & Decoder
Make text safe to put in a URL, or read an encoded URL back. The one choice that matters — a value or a whole URL — is right here at the top.
How to use it
- Pick Encode or Decode.
- Say whether this is a value going inside a URL or a whole URL. That single choice is what most broken links come down to.
- Paste your text. The result updates as you type.
A value or a whole URL?
A URL has punctuation that does a job: : ends the scheme,
/ separates path segments, ? starts the query
and & separates one parameter from the next. Those
characters are called reserved, and whether they should be
encoded depends entirely on which of the two things you are holding.
If you are putting one value into a query string
— a search term, a file name, a redirect address — every
reserved character in it must be escaped. Otherwise an &
inside your value ends the parameter early and the rest of it becomes
a parameter of its own. That is the encodeURIComponent
behaviour, and it is the right default.
If you are holding a whole URL that simply contains a
space or an accented character, escaping the punctuation would destroy
it: https:// would become
https%3A%2F%2F and it would stop being a link at all. That
is the encodeURI behaviour, which leaves the structure
alone and only fixes the characters that are never allowed.
Neither is more correct than the other. Picking the wrong one is what turns a working link into a 404.
Frequently asked questions
What is the difference between encodeURI and encodeURIComponent?
encodeURIComponent escapes the reserved punctuation - : / ? # [ ] @ ! $ & ' ( ) * + , ; = - because it assumes your text is one value being dropped into a URL. encodeURI leaves that punctuation alone because it assumes your text is already a URL and its punctuation is doing a job. Use the first for a query parameter, the second for a whole address.
Why is a space sometimes %20 and sometimes a plus sign?
Both are correct, in different places. Percent-encoding says a space is %20. The older HTML form format, application/x-www-form-urlencoded, says a space is +. Query strings written by browser forms use +, so many servers accept either. In a path, + is a literal plus and never a space - which is why tick the option only when you are building form data.
Why did my plus sign turn into a space when I decoded?
Because the plus-for-spaces option was on. In form data + really does mean space, so decoding has to turn it back. If your text contains a genuine plus - a phone number, a C++ reference - leave that option off, or the plus is read as a space and quietly lost.
What happens if the text is not valid percent-encoding?
Decoding says so instead of guessing. A stray % that is not followed by two hex digits, or a byte sequence that is not valid UTF-8, makes decodeURIComponent throw; this page catches that and tells you where the text is malformed rather than handing back something half-decoded.
Is this the same as HTML escaping?
No, and mixing them up is a common bug. Percent-encoding makes text safe inside a URL. HTML escaping makes text safe inside a page, so that a < is not read as the start of a tag. They solve different problems and use different characters - if you need the second one, use the HTML entity encoder on this site.
Is my text sent anywhere?
No. Everything happens in JavaScript inside your own browser. Nothing is uploaded and nothing is saved - close the tab and it is gone.