A workshop title contains a plus sign and an ampersand. An AI assistant adds it to a link, the page opens, and the creator assumes the job is done. Yet the destination may receive a different title from the one the creator supplied. A working address can still carry the wrong request.
For business owners and independent creators, this is a useful boundary to understand when commissioning small automations. Building a link involves keeping its structure separate from the values travelling inside it. The review should check those recovered values, alongside the page a reader eventually sees.
Start with the values you intend to send
Consider a fictional workshop catalogue. Its intended search title is Print + Play & Learn, and its session label is Autumn #1. For this example, imagine the catalogue expects query fields named q and session. Those names are assumptions for the exercise, not documented parameters of a real booking service.
The proposed base address is https://example.com/workshops. An assistant could try joining that address, the field names and the labels directly into one string. But characters inside a label can then be interpreted as part of the address’s structure.
The WHATWG URL Standard, last updated on 19 October 2026 when checked, specifies the form-style query parsing used by URLSearchParams. An ampersand separates name–value pairs, and a plus sign in that encoded input is converted to a space. Its serializer encodes spaces as plus signs. A literal plus inside a value therefore needs a different representation from a space.
This behaviour belongs to that query format. It is not a rule that every plus sign everywhere in a URL means a space. Keeping the scope clear prevents a proposed repair from changing parts of the address that were already correct.
Let the query builder handle the labels
Node.js’s official URL documentation describes URL and its searchParams interface for reading and writing query parameters. It also documents methods for setting a field and retrieving its value. That gives a developer a way to supply a label as data rather than splice it into query syntax.
For the fictional catalogue, the checked JavaScript uses these three statements:
const url = new URL('https://example.com/workshops');url.searchParams.set('q', 'Print + Play & Learn');url.searchParams.set('session', 'Autumn #1');
Reading url.href then produces https://example.com/workshops?q=Print+%2B+Play+%26+Learn&session=Autumn+%231. Here the title’s literal plus becomes %2B, its ampersand becomes %26, and the session’s hash becomes %23. The plain plus signs represent spaces in this query encoding.
The unfamiliar appearance is not itself a defect. The relevant test is what the parser recovers. In a local Node.js v24.22.1 check, parsing that generated address returned the complete title Print + Play & Learn and session Autumn #1. The fragment was empty. Assertions comparing both recovered values with their original strings passed.
Compare the failure, not just the finished link
The same local check tried direct string concatenation with the unencoded labels. It recovered a title with three spaces between “Print” and “Play”, followed by a trailing space. The literal plus had become an additional space, and the ampersand had ended that field. It also produced an unintended empty field named Learn.
The session recovered as Autumn , while #1 became the URL fragment. This was a parser test on invented data, not a request to a live workshop service. It demonstrates exactly where the information changed without inventing a booking failure or claiming lost sales.
That comparison is more informative than saying a link “looks wrong”. The creator can hand a developer two explicit requirements: preserve the full title and preserve the full session label. The developer can then show whether the constructed address satisfies them.
Do not encode an already prepared value again
A second mistake is to manually encode the title and then give that encoded text to searchParams.set as though it were the original label. In the checked example, passing encodeURIComponent(title) into the setter produced another layer of encoding.
After parsing that address once, the recovered value was Print%20%2B%20Play%20%26%20Learn, rather than the intended workshop title. The literal percent sequences remained part of the value. The check confirmed that this recovered value was not equal to the original label.
For this workflow, give the original value to the query builder once. If an existing system supplies encoded data, ask the developer to establish what representation it supplies and what the next component expects. Repeatedly encoding or decoding until a link looks readable is not a sound acceptance test.
Give an assistant a precise link-building brief
A useful proposed AI brief would identify the approved base address, the actual destination’s parameter names and the original values. Ask it to use the appropriate query-building interface, show the generated address and show the parsed values recovered from it. Require unsupported assumptions about the destination to be labelled.
Use representative labels containing spaces and punctuation in the test set. For each one, compare the recovered value with the input exactly. Keep those checks separate from whether the destination recognises the field name, finds a matching workshop or requires an account.
This article’s local check establishes JavaScript construction and parsing behaviour. It does not establish that any particular website accepts q or session, nor that a booking journey works. Those questions need the real service’s documentation and an authorised test of the intended route.
MaryChuks.com’s guide to checking a printed QR code’s finished reader journey covers the wider destination test. Once a link is placed in a newsletter, button or code, review the delivered version and follow it through to the promised material.
Keep the original values, the generated address and the check results together. When a label or destination changes, repeat the relevant review. A useful AI-assisted link preserves what the creator meant to send and supports the action the reader was invited to take.
Sources
- WHATWG URL Standard — form-style query parsing, serialising and URLSearchParams; last updated 19 October 2026.
- Node.js: URL documentation — current API documentation checked 30 October 2026.
The fictional example was checked locally in Node.js v24.22.1. No live catalogue, booking or payment request was made.
Discover more from Marychuks.com AI, Psychology, Business & CreativeVerse
Subscribe to get the latest posts sent to your email.