URL Encoder / Decoder
Percent-encode or decode URLs and URL components, with the distinction between full-URL and component encoding made explicit.
Runs entirely in your browser. Your input is never sent to our servers.
What is URL Encoder /?
URL encoding, also called percent-encoding, replaces characters that have a reserved meaning in a URL — or that cannot appear in one at all — with a percent sign followed by their hexadecimal byte value, so the data survives transmission without changing the structure of the URL.
What this URL Encoder / Decoder does
This tool encodes and decodes percent-encoded text, and lets you choose the scope that matters: whether you are encoding a single component of a URL, such as one query parameter value, or a whole URL that must keep its delimiters intact.
That choice is the reason most encoding bugs happen. Component encoding escapes &, =, ?, / and #; whole-URL encoding deliberately leaves them alone so the address still parses. Use the second where the first was needed and a value containing an ampersand silently splits into two parameters.
How to use it
- Choose Encode or Decode.
- Pick the scope. Component for a single parameter value or path segment; Whole URL for a complete address.
- When decoding form data, enable Treat + as space — HTML form submissions encode spaces as
+, which percent-decoding alone will not reverse. - Copy the result.
Understanding your results
Unchanged output is a valid result, not a failure. If every character is already safe in that position, correct encoding returns the string as it was.
Space becomes %20 or + depending on context. In a path or a modern query string it is %20; in application/x-www-form-urlencoded bodies it is +. The two are not interchangeable everywhere.
Non-ASCII characters expand. They are encoded as UTF-8 first, so one character often becomes several percent-escapes — é is %C3%A9, two bytes.
Why this matters
Encoding errors are a correctness problem and a security problem at once. A parameter value that is not encoded can inject additional parameters, and if the receiving application trusts the last occurrence while a filter inspected the first, the two disagree about what the request says.
Double-decoding is the related hazard. When one layer decodes a value and passes it to another that decodes again, %252e%252e%252f becomes %2e%2e%2f and then ../ — a path traversal that passed inspection because it was not yet traversal when it was inspected.
Common mistakes
Encoding a whole URL when you meant one parameter. The delimiters survive, so the value is not actually protected.
Decoding twice. Each layer should decode exactly once; decoding again turns escaped escapes into live characters.
Assuming + always means space. True in form-encoded bodies, not in a path segment, where + is a literal plus.
Limitations
This handles percent-encoding only. It does not encode or decode HTML entities, Base64, or JavaScript string escapes, which solve different problems and are not interchangeable.
It does not validate that the result is a well-formed URL — only that the encoding is correct.
Frequently asked questions
What is the difference between encodeURI and encodeURIComponent?
encodeURIComponent escapes the reserved delimiters & = ? / # so a value cannot alter the structure of the URL. encodeURI leaves them intact so a complete URL remains parseable. Use the first for a single value, the second for a whole address.
Why did my output come back identical?
Because every character in it was already safe in the position you chose. That is the correct result — encoding only changes characters that need changing.
Should a space be %20 or +?
In a path or a URL query string, %20. In an application/x-www-form-urlencoded request body, +. Decoders for form data treat + as a space; generic URL decoders do not.
Is URL encoding a security control?
No. It preserves structure, it does not sanitise content. Encoding a value correctly stops it breaking the URL, but the receiving application must still validate what the value contains.
References
Last reviewed