Percent-encodes text with the browser's encodeURIComponent, the strict variant that leaves only letters, digits, and - _ . ! ~ * ' ( ) untouched. Everything else, including / : ? & = and every multibyte character, becomes UTF-8 bytes written as %XX pairs.
This is component encoding, not whole-URL encoding
Because encodeURIComponent escapes the URL's own structural characters, pasting a complete URL into encode mode produces something like https%3A%2F%2Fexample.com%2F... — no longer a working URL. That output is wrong if you wanted a clickable link, and exactly right if you are embedding that URL as a parameter value, say a redirect_uri or a ?url= argument. The sibling function encodeURI preserves structure and only escapes genuinely illegal characters, but that is not what runs here, so encode individual values (a search term, a filename, one query parameter) rather than assembled URLs.
Note the UTF-8 step: é does not become one escape but two, %C3%A9, because percent-encoding operates on bytes and é is two bytes in UTF-8. Decoding reverses both layers at once.
Questions people ask
Why do + signs survive decoding when everything else in the query string comes back readable?
No. Plus-as-space is a convention of the application/x-www-form-urlencoded format used by HTML form submissions, not part of percent-encoding itself. decodeURIComponent deliberately leaves + alone, so a+b decodes to a+b. If your string came from a form submission, replace + with %20 before decoding.
Why does decode mode show 'Decoding failed' on my input?
A % that is not followed by two hex digits makes the whole string malformed: decoding '100%' throws URIError: URI malformed, and this tool surfaces that as the error banner. A literal percent sign must be written %25. The same error appears for truncated escapes, like a %C3 whose second byte was cut off.