Product links often include option names or filters containing spaces, ampersands, or plus signs. Encode the individual value—not the entire URL—so the browser and your ecommerce platform can tell data apart from URL separators. This guide shows how to build a product-option URL and check that the receiving page gets the intended value.
Key Takeaways
- Encode each value according to where it appears: a path segment or a query parameter.
- Use
URLandURLSearchParamsto construct query strings instead of concatenating values by hand. - In query strings, a literal
+may be interpreted as a space. Encode a plus sign as%2Bwhen it is part of the value. - Check your ecommerce platform’s URL conventions, especially for variant IDs, product slugs, and filter parameters.
Path segments and query values are different
A URL has structural separators. In a URL such as https://shop.example/products/t-shirt?variant=blue, the slashes divide path segments, while ? begins the query string and & separates query parameters. A character that is ordinary data in one part can have a special meaning in another.
For example, an ampersand in a query value must not be confused with the separator between parameters. A plus sign is another common trap: form-style query parsing treats + as a space. In a path, + is generally a literal plus, but encoding a value consistently avoids ambiguity across systems.
A space in a path segment is commonly represented as %20. In a query string created with URLSearchParams, spaces are serialized as +; a literal plus sign is serialized as %2B. Both representations can be correct in their respective contexts.
Build a product-option query safely
Use the URL APIs to add an option value. This example runs in modern browsers and in supported Node.js versions with the global URL API:
const productUrl = new URL("https://shop.example/products/t-shirt");
productUrl.searchParams.set("option", "Blue & White + 2XL");
console.log(productUrl.toString());
// https://shop.example/products/t-shirt?option=Blue+%26+White+%2B+2XL
searchParams.set() handles the query value’s encoding and replaces any existing option parameter rather than adding a duplicate. The ampersand becomes %26, so it stays inside the value; the plus becomes %2B, so it is not mistaken for a space.
The receiving page can read the value with the matching URL API:
const receivedUrl = new URL(
"https://shop.example/products/t-shirt?option=Blue+%26+White+%2B+2XL"
);
const option = receivedUrl.searchParams.get("option");
console.log(option);
// Blue & White + 2XL
Check the value after parsing, not just the encoded text in the address bar. The intended result is the original option string, with the ampersand and plus sign intact.
Encode a value for a product path
If a platform puts an option or product identifier in one path segment, encode that segment rather than the whole path. In JavaScript, encodeURIComponent() is intended for an individual URI component:
const option = "café & tea +";
const encodedOption = encodeURIComponent(option);
console.log(encodedOption);
// caf%C3%A9%20%26%20tea%20%2B
const productUrl = `https://shop.example/products/${encodedOption}`;
console.log(productUrl);
// https://shop.example/products/caf%C3%A9%20%26%20tea%20%2B
This example treats the value as exactly one path segment. If the value is meant to contain multiple segments, do not encode the slashes as if the whole path were one value; build and encode each segment according to the platform’s routing rules.
Component encoding is not whole-URL encoding
Do not pass a complete URL to encodeURIComponent() when you intend to create a clickable URL:
encodeURIComponent("https://shop.example/products/t-shirt?variant=123");
// https%3A%2F%2Fshop.example%2Fproducts%2Ft-shirt%3Fvariant%3D123
That result is one encoded component, not a normal navigable URL: the scheme, slashes, question mark, and equals sign have all been encoded as data. Conversely, do not concatenate an unencoded value into a URL and assume its punctuation will remain part of that value.
Build the URL with URL and set components with searchParams, or use encodeURIComponent() only on an individual value when constructing a path segment. Avoid encoding an already encoded value a second time; for example, %2B can become %252B through double encoding.
Example: filters with multiple values
Suppose a search page has a color filter called Blue & Green and a size filter of 2XL+. Add each value separately:
const filterUrl = new URL("https://shop.example/search");
filterUrl.searchParams.set("color", "Blue & Green");
filterUrl.searchParams.set("size", "2XL+");
console.log(filterUrl.toString());
// https://shop.example/search?color=Blue+%26+Green&size=2XL%2B
Here, the unencoded & between parameters is a URL separator. The ampersand in Blue & Green is encoded as %26, and the plus sign in 2XL+ is encoded as %2B. Reading the parameters with searchParams.get("color") and searchParams.get("size") returns the original values.
Check your ecommerce platform’s URL conventions
Correct character encoding does not determine which URL shape your store supports. A platform might identify a variant with a stable ID, use a specific query parameter, or represent filters in its own path or query format. Prefer the platform’s documented URL structure over inventing a parameter based on a display label.
Test a link from end to end: open it, confirm the intended product option or filters appear, refresh the page, and check that copying and sharing the URL preserves the selection. If the platform transforms the URL, compare the final address with its documented convention. For a quick visual check of URL components, you can use a [URL Encoder Decoder](URL Encoder Decoder); still verify the result in your store, since a generic encoder cannot confirm that the platform recognizes a particular variant or filter.
Common Mistakes
- Encoding the whole URL as one component, which turns URL structure into encoded data.
- Manually inserting values containing
&into a query string, where the ampersand may start another parameter. - Treating
+in a query as guaranteed to mean a literal plus; form-style query parsing commonly reads it as a space. - Encoding values twice, producing sequences such as
%2526instead of%26. - Assuming a correctly encoded link is a valid product or filter URL for every ecommerce platform.
- Confusing URL encoding with HTML escaping. If a URL is inserted into HTML, use the framework’s normal safe templating or attribute-escaping mechanism as well.
Best Practices
- Use URL-building APIs instead of hand-built query strings.
- Encode values at the boundary where they become a URL component, and decode them only once when reading them.
- Prefer stable variant identifiers when the platform supports them; display names can change or contain punctuation.
- Test representative values with spaces,
&,+, accented characters, and multiple filters. - Confirm the resulting URL with the actual store’s routing and sharing behavior.
Conclusion
To encode special characters in a product URL, first identify whether the value belongs in a path segment or a query parameter. Encode that component while preserving the URL’s separators, then verify that the store interprets the decoded value as the intended option or filter.
