URL encode with the right escape set

encodeURIComponent, unless you are handing it a complete URL. The difference is what each one considers structure: encodeURIComponent escapes the delimiters : / ? # & = + $ , ; @ because it assumes your string is a single value being placed inside a URL, while encodeURI leaves all of them alone because it assumes your string already is the URL and those characters are doing their job. Roughly: build the parts, encode each part with encodeURIComponent, join them; use encodeURI only to tidy up a finished link that has a space or an accent in it.

Because it was encoded as a value, so the characters that make it a URL were escaped along with everything else. https://example.com/a?b=c comes back as https%3A%2F%2Fexample.com%2Fa%3Fb%3Dc — a perfectly correct escaping of that text, and no longer a link anything can follow. This page detects a whole URL in the box and says so. The one place that escaping is right is when a URL is the value of a parameter in another URL, which is exactly how a redirect or a callback parameter is meant to look.

Because they are two different specifications that were written twenty years apart. encodeURIComponent comes from ECMAScript and follows the older RFC 2396 idea of unreserved characters, which included the six marks ! ' ( ) * ~; the WHATWG URL standard defines the form-urlencoded serializer with a larger escape set and keeps only letters, digits and * - . _ . Both decode back to the same string, so nothing breaks — but if you are comparing your output against what a browser posted, or building a signature the server recomputes, the two will not be byte-identical.

Yes, always, and as %2F. A slash is the segment separator, so a filename like invoices/2026 written raw into a path creates a directory boundary that was never in the data. Encoding it is the correct fix, but be warned that it is only half a fix in production: Apache rejects %2F in a path with a 404 unless AllowEncodedSlashes is turned on, and some proxies normalise the escape back to a slash before your application sees it. Where that bites, the value belongs in the query string instead.

Use the strict panel, the fourth one. RFC 5849 §3.6 requires OAuth 1.0a to percent-encode everything outside the RFC 3986 unreserved set — A-Z, a-z, 0-9 and - . _ ~ — and AWS Signature Version 4 asks for the same when it builds a canonical request. Plain encodeURIComponent leaves ! * ' ( ) unescaped, so a value containing any of those produces a different string from the one the server signs, and the request fails with a signature mismatch that says nothing about which character caused it.

Because percent-encoding works on bytes, and that emoji is four of them. Encoding converts the text to UTF-8 first, then writes each byte that cannot appear literally as three characters — a percent sign and two hex digits. 😀 is F0 9F 98 80, so it leaves as %F0%9F%98%80. The same arithmetic applies further down the scale: é is two bytes and becomes %C3%A9, 東 is three and becomes %E6%9D%B1. Anything that produces a two-character escape for an accented letter is encoding in Latin-1, and the value will not survive a UTF-8 reader.

Yes — once, with the component set, and then leave it alone. The failure people hit is encoding it twice, usually because one layer of a framework already did it: the target arrives as https%3A%2F%2F… , gets encoded again into https%253A%252F%252F… , and the receiving service redirects to a nonsense address or refuses the request. If you are looking at a value with %25 in front of every escape, that is what happened, and the decoder on the other page unwinds it round by round.