URL Encoding Explained: Percent Encoding, Query Strings, and Safe Links
URL Encoding Explained: Percent Encoding, Query Strings, and Safe Links
A technical article on percent encoding, query parameters, path segments, form encoding, and why URLs break when reserved characters are copied raw.
Original workflow visual
URL Encoding Explained: Percent Encoding, Query Strings, and Safe Links
Identify part
Review before moving forward
Encode value
Review before moving forward
Test link
Review before moving forward
A full URL can include scheme, host, path, query, and fragment. Each part has its own rules. A slash inside a path means something different from a slash inside a query value. Encoding should happen at the component level, not by blindly encoding or decoding the entire URL. If you encode the whole URL, you may hide structural separators. If you encode nothing, data characters may be interpreted as structure.
Percent encoding writes a byte as percent followed by two hexadecimal digits. Spaces, non-ASCII text, and reserved characters can be represented this way after choosing an encoding such as UTF-8. For example, a query value containing an ampersand must encode that ampersand so it does not split the parameter. The goal is not decoration; it is preserving data boundaries.
Query strings commonly use name=value pairs separated by ampersands. Both names and values can require encoding. A value such as "red & blue" should not be pasted raw, because the ampersand may start a new parameter. Rebuilding query strings with a structured API is safer than string concatenation. It also handles repeated keys, empty values, and ordering more predictably.
In application/x-www-form-urlencoded data, a plus sign often represents a space. In other URL contexts, plus can be a literal plus. This difference causes bugs in search URLs, email links, and encoded tokens. If a value contains plus signs that matter, test the exact parser that will receive the URL. Do not assume all URL decoding rules are identical across path, query, and form bodies.
Double encoding happens when an already encoded value is encoded again. A percent sign becomes %25, so %20 can turn into %2520. The receiving system decodes once and still sees encoded-looking text. Double decoding is also risky because it can turn safe-looking strings into active separators. A clear workflow should mark whether a value is raw, encoded once, or already part of a URL.
The fragment after a hash is handled by the browser and usually not sent in HTTP requests. This matters for debugging analytics, authentication redirects, and client-side routing. Encoding a value into the fragment can be useful for browser-only state, but the backend will not see it in the normal request path. If the server needs the value, put it in the path or query according to the API design.
Start by identifying the URL component you are building. Keep raw values separate from structural separators. Encode each path segment or query value with a component-aware API. Build the URL, parse it back, and confirm the resulting parameters match what you intended. For user-generated links, validate allowed schemes and hosts too. Encoding preserves syntax; it does not decide whether a destination is safe.
Common Questions
Usually encode individual components such as path segments and query values, then assemble the URL structure.
The percent sign was encoded again, which is a common sign of double encoding.
It prevents syntax confusion, but it is not a complete security control. You still need validation and authorization.
Test spaces, ampersands, plus signs, equals signs, non-ASCII text, empty values, repeated keys, and values that already contain percent signs. These cases reveal whether your code is encoding raw values once or accidentally encoding an already assembled URL.
Some applications auto-decode, re-encode, trim punctuation, or treat plus signs and spaces differently. Messaging apps may also include trailing punctuation in the link. Parse the URL and inspect each component instead of judging only by the visible text.
Yes, but also validate them. Encoding preserves the redirect value as data; it does not prove the destination is allowed or safe.
Structured URL APIs understand components and reduce string-concatenation mistakes. Manual concatenation is where double encoding and broken separators usually enter.