URL encoding is simple when you are clear about what you are encoding. Problems start when a full URL, a query parameter and a path segment are treated as if they were the same thing.
Percent-encoding represents special bytes
A space can appear as %20, and a slash can appear as %2F when it is data rather than a path separator. The exact characters that need encoding depend on where the value sits inside the URL.
Encode the component, not blindly the whole URL
Suppose a query parameter needs the value red & blue. The ampersand has structural meaning in a query string, so the value needs encoding before you insert it. Encoding the complete URL afterward can also encode separators such as :, /, ? and & that are supposed to remain structural.
Why double-encoding is so confusing
The percent sign in %20 can itself be encoded as %25. If an already encoded value is encoded again, %20 becomes %2520. When you see lots of %25 sequences, double-encoding is worth investigating.
Plus signs are context-sensitive
Traditional form encoding can use + for a space in query data, while literal plus signs may need to be encoded. Do not assume every decoder treats plus signs identically outside that context.
International text should use a consistent character encoding
Modern web applications normally work with UTF-8. Non-ASCII text is converted to bytes and those bytes can then be percent-encoded. Mismatched encodings are a common cause of garbled decoded text.
A debugging routine
- Identify the exact component: path segment, query key or query value.
- Look at the raw value before encoding.
- Encode once.
- Inspect the final URL structure.
- Decode once and confirm you recover the original value.
The goal is not to make a URL look complicated. Encoding exists so data and URL syntax do not get mistaken for each other.