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.
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.
