Is the object returned by a URL instance's searchParams property a live view of that URL or a detached snapshot, and what breaks in a helper that works on new URLSearchParams(url.search) instead?

## The property is an accessor, and it is live `URL.prototype.searchParams` is a getter with no setter. It returns the *same* `URLSearchParams` instance for the lifetime of the `URL` object, and that instance is wired to the URL's query component in both directions. ```js const url = new URL('https://api.test/items?page=1'); const p = url.searchParams; url.searchParams === p; // true — the same object every time p.set('page', '2'); url.search; // '?page=2' url.href; // 'https://api.test/items?page=2' url.search = 'page=9&sort=name'; p.get('sort'); // 'name' — the same object was re-populated ``` So there are two equivalent ways to edit the query on a `URL`: go through the params object, or assign a whole string to `url.search`. Both re-serialise `href`. Assigning `url.search = ''` clears the query and removes the `?` from `href`. Because the accessor has no setter, this fails: ```js 'use strict'; url.searchParams = new URLSearchParams('a=1'); // TypeError ``` Without strict mode the assignment is silently ignored, which produces the maddening "my code runs, nothing changes" bug. The correct spelling is `url.search = otherParams.toString()`. ## The detached copy `new URLSearchParams(url.search)` parses the query string into a brand-new object with no link back: ```js function addTracking(url) { const params = new URLSearchParams(url.search); // detached copy params.set('utm_source', 'newsletter'); return url; // BUG: url is unchanged } ``` The copy is not a mistake in itself — it is the right tool when you want to compute something without touching the original. It only becomes a bug when the author believes it is live. The fix is one line: ```js function addTracking(url) { const params = new URLSearchParams(url.search); params.set('utm_source', 'newsletter'); url.search = params.toString(); // write it back return url; } ``` Note that the constructor tolerates the leading `?` that `url.search` includes — it is stripped during parsing — while `toString()` emits no leading `?`, and the `search` setter accepts the string with or without one. ## Mutability is the deeper trap The live view is a symptom of something more important: **`URL` objects are mutable and passed by reference.** A helper that mutates the `URL` it was handed changes the caller's object too. ```js const base = new URL('https://api.test/items?page=1'); const tracked = addTracking(base); tracked === base; // true — the caller's URL was mutated ``` If `base` is a module-level constant reused for every request, that helper has permanently contaminated it, and each call appends more state. The disciplined pattern is to copy first and return a new object: ```js function withParam(url, name, value) { const next = new URL(url); // the URL constructor accepts a URL and stringifies it next.searchParams.set(name, value); return next; } ``` `new URL(url)` works because the constructor stringifies its argument via `href`, giving you a clean deep copy. Treating URL helpers as pure functions over immutable inputs removes an entire class of "why does this request carry last page's filters" bugs. ## Ordering and iteration while mutating One more consequence of liveness: `set` keeps a replaced key in its original position, while `append` and a set-on-a-missing-key add at the end. So repeatedly toggling a filter can reorder the query string even though the pairs are the same. If a stable string matters — comparing URLs, using one as a cache key, snapshot-testing a link — call `params.sort()` before serialising, which sorts pairs by name and preserves the relative order of values sharing a name. Also avoid mutating while iterating the live view. Deleting entries inside a `for...of` over the same params object can skip pairs, exactly as it would with any list you edit during traversal. Snapshot first with `[...params]` or `params.getAll(name)`, then mutate. ## Why interviewers ask This question separates people who have read the property from people who have debugged it. The read-only accessor, the silent no-op assignment in sloppy mode, and the detached-copy write-back are all real bugs that produce no error and no stack trace — the URL simply is not what you expected when the request goes out.