Three things about URL encoding that actually trip people up in practice, and everything else is just documentation.
First: encodeURI vs encodeURIComponent in JavaScript. They sound similar and they're not. encodeURI leaves /, ?, &, =, :, # alone — it assumes you're encoding a full URL. encodeURIComponent encodes all of those too — it assumes you're encoding a single query parameter value. Use the wrong one and you get a URL where & shows up unencoded inside a parameter, silently splitting your query string into two. The rule is simple: if it goes inside a parameter value, use component. If it's the URL itself, use URI. One exception: never encodeURIComponent an entire URL, you'll turn the slashes and colons into %2F and %3A and the browser won't recognize it as a path.
Second: the + vs %20 war. HTML form submissions encode spaces as + (application/x-www-form-urlencoded). But in URLs, spaces become %20. They mean the same thing to most decoders but + inside encodeURIComponent output is literal-plus, not space. So if you're decoding form-encoded data and you see a +, you probably want a space. If you're decoding URL-encoded data and you see a +, you probably want a literal +. This tool handles both, but you need to know which convention you're dealing with.
Third: the double-encode bug. You percent-encode a value, then the framework encodes it again. Your %20 becomes %2520. This is the number one encoding-related bug I see in the wild. Check your encoded strings — if you see %25 anywhere, that's a percent sign that got encoded twice somewhere in the pipeline.
If you're encoding a query parameter that contains a URL (like a redirect target), you encode twice — once for the URL itself, then again as a query parameter. The order matters.
The tool's "Full" mode encodes everything, "Component" leaves the structural URL characters alone. Both have their place — just make sure you pick the one that matches where the string is going, not what looks prettier.
UTF-8 is the default here, and it's the right choice unless you have a very specific historical reason not to. Every percent-encode of a non-ASCII character starts from the UTF-8 byte sequence of that character. Encode the same emoji as UTF-16 and you'll get different percent-encoded sequences entirely.