Encode, decode and take a URL apart. Both encoders shown.
What it's for
Make a word or phrase safe to put inside a web link, turn a link full of codes like %20 back into readable text, or see a long web address split into its parts.
Before you start
Have the link or the piece of text to hand — copied from the browser's address bar, an email or a form. Nothing you paste leaves your browser.
Paste the address or the text
Paste it into URL or value, replacing the sample. It can be a whole web address or just one word or phrase.
Choose what to show
In Show, pick Encoded — one value for a single piece that goes inside a link, such as a search word or a name; this is the safe choice. Pick Encoded — whole URL only for a complete address whose spaces or accented letters need making safe. Pick Decoded to turn %20 and similar codes back into readable text.
Treat + as a space, if it came from a form
Tick Decode + as a space when the text came from a web form or a search box, where a space is written as +. Leave it off otherwise, because everywhere else + really means plus.
Convert and copy
Press Convert to bring the answer into view — it also updates as you type. Press Copy at the top to take it.
Reading the result
If it goes wrong
The two encoders are not interchangeable, and that is the whole tool.
encodeURIComponent escapes / ? : @ & = + $ # — for one piece going into a URL. encodeURI does not — for a whole URL that is already assembled.
Using the second where the first is needed is the commonest URL bug there is: a value containing & splits into two parameters, and one containing # truncates the URL at the fragment. Both look like a server fault and are not.
And a plus is a space in a query string and nowhere else. A form encodes a space as +; the URL specification uses %20. So a decoder that converts every plus corrupts a genuine one in a path.
If you are encoding ONE PIECE going into a URL — a query value, a path segment — use the component form, which escapes the reserved characters / ? : @ & = + $ and #. If you are encoding a URL that is already fully assembled, use the whole-URL form, which leaves those alone because they are doing their job. Getting this backwards is the commonest URL bug there is.
The reserved characters survive unescaped and change the meaning of the URL. A value containing & splits into two query parameters. A value containing # truncates the URL at the fragment, so everything after it never reaches the server. Both look like a server fault and are not.
It depends where it is. In a query string produced by an HTML form, a space is encoded as +. Everywhere else in a URL a space is %20 and a + is a literal plus. So decoding + as a space corrupts a genuine plus in a path, and not decoding it leaves pluses through a form value. It is a switch on this page, defaulting to off.
It contains a % that does not begin a valid escape — “100% sure” is the usual culprit. Decoding throws on that, so the text is shown unchanged with a note rather than an error, because you pasted it to see what it is.
Because repeating a key is legal and every framework handles it differently — some keep the first, some the last, some build a list. Collapsing them here would hide a real ambiguity, so all of them are shown and the page says the behaviour depends on what is reading it.
Nothing you paste leaves your browser, so it is safe from us. It is not safe generally: a password in a URL ends up in server logs, browser history and Referer headers, so a URL that has ever carried one should be treated as exposed. This page masks it rather than displaying it back to you.
The second changed nothing. As a query value that has already split into two parameters and truncated at the fragment.
Important
Runs entirely in your browser; nothing is transmitted. Both encodings are shown because using the whole-URL form where the component form is needed is the commonest URL bug — and it produces a URL that looks correct. Nothing you type here is sent to our servers — the calculation runs entirely in your browser.
