A URL contains structure and data at the same time
A web address is not one undifferentiated string. Characters such as a question mark, ampersand, equals sign, slash and hash can define parts of the URL itself. The same characters can also appear as ordinary data inside a search term, file name or tracking value. Encoding is the mechanism that prevents a data character from being mistaken for a structural separator. Percent-encoding represents a byte with a percent sign followed by two hexadecimal digits. A space, for example, is commonly represented as %20 in a URL component. Understanding which part of the URL you are encoding is more important than memorizing a list of replacements.
Encode values, not an entire finished URL blindly
A frequent mistake is to paste a complete URL into an encoder and encode every structural character. If https://, slashes, the query question mark and parameter separators are all encoded, the result may no longer function as the same web address. Usually you encode the individual data value before placing it into the URL structure. For example, a search parameter containing a phrase with spaces and an ampersand should have that phrase encoded so the ampersand is not interpreted as the start of a second parameter. The surrounding question mark, equals sign and separator ampersands should remain structural characters unless the application specifically expects an encoded URL as data.
Reserved characters have meaning in particular components
Some characters are reserved because they can act as delimiters. A slash separates path segments, a question mark begins the query component, a hash introduces a fragment, and ampersands commonly separate query parameters. Whether a reserved character needs encoding depends on its role. A slash that separates folders should remain a slash; a slash that belongs literally inside one query value may need encoding. This context-sensitive rule explains why replacing characters across the whole URL can produce confusing results. Build or parse the URL into components first, then encode the user-controlled value for the component where it will be placed.
Query-string spaces may appear as %20 or plus signs
HTML form encoding commonly represents spaces with a plus sign in query data, while generic percent-encoding uses %20. Both forms are widely encountered, but they are not interchangeable in every context. A literal plus sign in a form-encoded value may need to be encoded so it is not interpreted as a space. Frameworks often handle this distinction automatically, which is why manual string concatenation can create subtle bugs. If an API specifies how its query parameters should be encoded, follow that documentation and use a URL-building library when possible.
Decoding should be applied at the correct layer
Decoding converts percent-encoded sequences back to their represented characters. Double decoding is dangerous because a value may intentionally contain an encoded percent sequence. If software decodes it once and then decodes the result again, characters that were meant to remain data can become active delimiters. This matters for security as well as correctness. Applications should normally decode according to the URL parser or framework's rules rather than repeatedly calling a decoding function until the text stops changing. When troubleshooting, identify whether you are looking at the raw URL, a parsed parameter or a value that has already been decoded.
Non-ASCII text is encoded as bytes
Characters outside basic ASCII, including many accented letters, Arabic, Urdu and emoji, are normally represented using UTF-8 bytes and then percent-encoded when required in a URL component. That is why one visible character can become several percent sequences. The longer encoded form does not mean the text is corrupted; it reflects the underlying byte representation. Problems occur when one system encodes text using one character set and another system decodes it using a different assumption. Modern web applications should use UTF-8 consistently unless a legacy protocol explicitly requires something else.
Test the final URL as the receiving system will see it
After encoding a parameter, verify both the visible URL and the value the destination application receives. A correct-looking address can still be wrong if the value was encoded twice or if a delimiter was left unencoded inside user data. ToolsDiary's URL Encoder and Decoder is useful for inspecting individual components, while URL Parser can help separate a full address into its structural pieces. For application code, prefer standard URL APIs that let you set query parameters as values so the library can perform the necessary encoding instead of manually joining strings.
Frequently asked questions
What does %20 mean in a URL?
It is the percent-encoded representation commonly used for a space byte in a URL component.
Should I encode https:// in a normal web address?
Usually no. The scheme and structural separators belong to the URL itself. Encode the data component that needs protection from delimiter interpretation.
Why does an ampersand break my query value?
An ampersand commonly separates query parameters. If it belongs inside one parameter value, it generally needs to be encoded.
Is URL encoding encryption?
No. Percent-encoding is a representation rule. Anyone can decode it, so it must not be treated as protection for secrets.
Can I decode a URL repeatedly?
Avoid repeated or blind decoding. Decode at the correct parsing layer because double decoding can change data into active delimiters and create correctness or security problems.
This guide is informational and is reviewed against the public behavior of the tools described. See our editorial policy.