Why your link loses data: fix query parameters and fragments

A page that opens may not receive what you expected

You prepared a link to a search for coffee and tea. The page opens, but the results do not match your intention. Before blaming the server or shortener, inspect the exact address you shared. In our fictional example, q=cafe&te does not represent a single cafe&te value under the usual form-parameter interpretation: & separates entries. Also, #precios marks a fragment. Replace example.invalid with your own page that supports the query before testing a real address.

Split the diagnosis into three questions: which page should open, which data should it receive and which part should appear afterwards? Copy the link’s URL rather than only the button’s visible label. Save a reference version before editing. This guide suggests reviewing the components and then checking the result with WikiURL; it does not promise every website recognises q or that a successful response means correct search results.

https://example.invalid/buscar?q=cafe&te#precios

If the ampersand belongs to the text, do not use it as a separator

To search literally for cafe & te, the ampersand belongs inside the q value. When building parameters with URLSearchParams, provide unencoded text; serialisation represents that character as %26. MDN explains that this interface applies form encoding when converting parameters to text and represents spaces with +. That does not mean you should replace every ampersand in a URL: some intentionally separate parameters.

The JavaScript example creates an address from a base, assigns the search value and adds the fragment separately. You can run it locally in a JavaScript environment to see the result without sending a search to the fictional domain. If you do not program, use the link generated by your own search page instead of concatenating text manually. Compare the expected value with the website’s results; seeing %26 in a link does not establish how a particular application interprets the data.

const url = new URL("https://example.invalid/buscar");
url.searchParams.set("q", "cafe & te");
url.hash = "precios";
console.log(url.href);
// https://example.invalid/buscar?q=cafe+%26+te#precios

A fragment is not a parameter received by the server

MDN documents that the fragment after # is processed by the client and is not sent to the server when requesting the resource. A page may use it to reach a section such as precios or for another application behaviour. Therefore, putting q=cafe#te does not make te complete the value received by the server in that request. If # belongs to the search text, its representation inside the value is %23, as the third address illustrates.

Check the two effects separately: the search must show the intended results and the fragment must reach the desired place. The section must exist or the application must recognise that fragment. A checker requesting the website from a server does not by itself confirm that the browser scrolls to a section. Do not delete all fragments as a universal fix either: you could remove exactly the part the recipient needed.

https://example.invalid/buscar?q=cafe%23te#precios

Encode the value once, rather than the entire address

RFC 3986 distinguishes characters delimiting components from data and warns against repeatedly encoding or decoding the same string. If you supply cafe%26te as already encoded text to a function expecting an unencoded value, the percent sign can become %25, producing %2526. You have added a layer rather than automatically preserved the desired search. The two example lines help identify that change.

The correction depends on the data’s origin. If it starts as human text, pass it unencoded to the parameter-building interface. If it starts as a complete valid URL, do not treat it as one value and re-encode the whole address. Document what each function or form receives. Avoid global search-and-replace fixes for %, & or #: you could alter correct delimiters, necessary parameters or paths you did not intend to change.

q=cafe%26te
q=cafe%2526te

Use WikiURL for the response and your browser for the content

Once you have a real public address, paste it into WikiURL’s URL checker. Review the returned HTTP status and final destination. The implementation requests from the server and follows redirects; that review helps locate unexpected destinations. Do not paste management links, passwords or addresses containing private data. Do not attempt to check example.invalid from our examples; it serves here as a fictional destination.

Also open the real version in your browser and inspect the search and section. A successful response can load a page without applying the expected filter. If there is a redirect, compare its parameters with your reference and observe the fragment in the browser. The checker does not interpret application logic for you, certify safety or prove a user account has permission to see the content. The aim is to combine response evidence with a functional review.

Test the copy another person will receive

Paste the final link into the channel where you will share it and open that copy before distributing it widely. Check that you did not include the sentence’s final period, lose part while copying or mistake visible text for the destination. Test without depending on your administrator session when the content must be public. If converting it to QR, also check the address displayed by scanning, alongside the source file.

Keep a small record: original address, expected search value, intended fragment, shared URL and observed result. If it fails, return to the specific component and repeat the test after correcting it. Publish only the checked version. You can then distinguish a parameter-construction problem from a redirect changing the destination or browser behaviour, without treating an opening link as a guarantee that it preserves every piece of data you intended to send.