URL Encoder and Decoder
Percent-encoding in both directions, with the component and whole-URL rules kept apart.
A URL can only carry a restricted set of characters, and several of those characters mean something structural: a question mark opens the query string, an ampersand separates parameters, a hash starts the fragment. Anything else has to be percent-encoded. Which characters count as "anything else" depends on whether you are encoding one value or an entire address — a distinction this tool makes explicit rather than guessing.
How it works
Choose encode or decode
The same rules apply in reverse when decoding.
Pick the scope
A single component encodes the structural characters too; a whole URL leaves them working.
Copy, or swap the result back in
Chaining a decode after an encode is a quick way to check a round trip.
Component or whole URL — the mistake behind most broken links
JavaScript offers two functions and the difference matters. encodeURIComponent escapes everything that is not unreserved, including & ? = / # +, and is correct for a single value being dropped into a query string. encodeURI leaves those characters alone because it assumes you are handing it a complete, already-structured address that must keep working.
Using the wrong one fails in opposite directions. Encode a whole URL with the component function and https://example.com/ becomes https%3A%2F%2Fexample.com%2F — a valid string that is no longer a link. Encode a single value with the URL function and a search term containing an ampersand splits into two parameters, silently truncating the search.
The rule that avoids both: encode values, not addresses. Build the URL from its parts, run each value through component encoding as you insert it, and never encode the assembled result a second time. Double-encoding turns %20 into %2520, which is one of the harder bugs to spot because it looks almost right.
Why a space is sometimes %20 and sometimes +
Both are correct, in different places. The percent-encoding standard defines a space as %20 and that form is valid anywhere in a URL. The plus sign comes from HTML form submission, where the application/x-www-form-urlencoded content type has encoded spaces as + since the earliest browsers and continues to for compatibility.
The consequence is a genuine ambiguity in query strings. A server parsing form-encoded data reads + as a space, so a literal plus sign in a value — a phone number such as +41 44 123, or a search for C++ — must itself be encoded as %2B or it disappears. Inside a URL path, by contrast, a plus is just a plus and no decoder converts it.
The safe default is %20, which every parser reads as a space in every position. Turn on the form-encoding option only when you are reproducing what a browser sends from an HTML form, or matching an existing API that expects that style.