Why URLs need encoding
URLs only allow a limited character set, and some characters have jobs: ? starts the query, & separates parameters, = assigns, # jumps to fragments. Any of those appearing inside a value — a search term, a redirect URL — must be percent-encoded (%26 for &) or the URL's structure breaks. Non-ASCII text becomes UTF-8 bytes, each byte percent-encoded: 你 → %E4%BD%A0.
%20 versus +
Both can mean "space," from two different standards: percent-encoding proper says %20; the older HTML form format (application/x-www-form-urlencoded) says +. Query strings commonly contain either; paths should only use %20. This decoder accepts both. In JavaScript, use encodeURIComponent for values — plain encodeURI leaves & and = untouched and is the source of a thousand broken redirect parameters.
Frequently asked questions
When do I need to URL-encode something?
Whenever user text goes inside a URL: search queries, redirect targets, filenames, anything in a query parameter. If a value could contain & ? = # % or spaces, encode it.
What's the difference between encodeURI and encodeURIComponent?
encodeURIComponent encodes everything with a structural meaning (& = ? # /) and is what you want for parameter values. encodeURI preserves those characters and only suits encoding a complete URL as a whole.
Why did my decoded text come out with weird characters?
Likely double-encoding (%2520 is an encoded %20) or a non-UTF-8 legacy encoding. Decode twice for the former; for the latter, the original site wasn't using UTF-8 and bytes need reinterpreting.
Are there characters I never need to encode?
Letters, digits, and - _ . ~ are 'unreserved' — always safe raw. Everything else is context-dependent, which is why encoding values wholesale is the safe habit.