A URL is not just a string — it’s a structure, and a handful of characters
carry structural meaning. ? starts the query,
& separates parameters, / separates path
segments, # begins the fragment. If your data contains one
of those, it has to be escaped or the URL falls apart. Toolsyy’s
URL Encode & Decode tool does it both ways.
The one rule that matters
Nearly every URL-encoding bug comes from getting this backwards. There are two jobs, and they are not interchangeable.
Encoding a single value
This is what you want almost every time. You have a piece of data — a search term, a name, an email address — and it’s going inside a URL as a parameter value. Everything with structural meaning must be escaped, because in your value those characters are just characters:
a&b=c → a%26b%3DcWithout that, a search for a&b=c would look like two extra
parameters and quietly break the request.
Encoding a whole URL
Here you have a complete address and you only want to fix genuinely illegal characters — spaces, accents — while leaving the structure intact:
https://example.com/my page → https://example.com/my%20pageThe slashes and colon survive because they’re doing their job.
Use the wrong one and you get the classic failure: encoding an entire URL as if
it were a value, turning https:// into
https%3A%2F%2F and producing something no browser will follow.
Toolsyy’s Query value and Whole URL settings correspond exactly
to these two jobs.
The one time whole-URL-as-a-value is correct: when a complete URL is
being passed as a parameter, such as
?redirect=https%3A%2F%2Fexample.com. There the inner URL really is
data.
Why a space is sometimes %20 and sometimes +
Both are correct, in different places, which is why this confuses everyone.
%20 is the general percent-encoding of a space and is valid
anywhere in a URL. The + convention comes from HTML form submission
— the application/x-www-form-urlencoded format — where a plus means
a space, but only within a query string.
In a path segment, a plus is a literal plus character. So
/my+file and /my%20file point at two different things,
while ?q=my+file and ?q=my%20file usually mean the
same. Because %20 is unambiguous everywhere, it’s the safer default
— and it’s what this tool produces.
Practical consequence: if a search for “C++” returns results for “C ”, some
layer has decoded your pluses as spaces. Encode them as %2B.
Double encoding, and the %2520 tell
If you ever see %2520 in a URL, you’re looking at a value that was
encoded twice. A space became %20; then something encoded that
string again, and the % itself became %25, giving
%2520.
It’s almost always two pieces of code both trying to help — a framework that
encodes automatically plus a developer encoding by hand. Decode once in the tool
and you’ll get %20 back, which confirms the diagnosis. The fix is to
remove one of the two encoding steps, not to add a decode.
What is never encoded
A fixed set of characters is always left alone, because they’re safe in every
part of a URL: letters, digits, and
- _ . ! ~ * ' ( ). If you see those unescaped, nothing is wrong.
FAQ
Why is a space sometimes %20 and sometimes a plus sign?
Both appear because two different specifications are in play. Percent-twenty is the general URL encoding for a space and is always safe. The plus sign comes from HTML form submission, where it means a space only inside a query string. In a path segment a plus is a literal plus, so percent-twenty is the safer choice everywhere.
Should I encode the whole URL or just one value?
Encode just the value in almost every case. Encoding a whole URL escapes the slashes, question mark and ampersands that give it its structure, producing a string that is no longer a working address. Whole-URL encoding is only for putting one complete URL inside another, such as a redirect parameter.
Why do I sometimes see %2520 in a URL?
That is a double encoding. A space became %20, then the percent sign
itself was encoded again into %25, giving %2520. It
almost always means a value was encoded twice by two different pieces of code.
Decoding it once returns %20, which reveals what happened.
Does URL encoding hide or protect data?
No. It is a formatting convention with no secrecy at all, and anyone can decode it instantly. It exists so that characters with special meaning in a URL can be transmitted literally, not to conceal anything.
Related guides
- Base64, explained — the other encoding you meet constantly, and why it isn’t encryption either.
- How to create a QR code — encoding a link for the physical world.
Try it now: Free URL Encoder & Decoder