Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

URLs and origins: separate location, query, and fragment

Last updated: 5 Oct 20266 min read
tutorial
IntermediateBy AITrove Editorial

A URL identifies a resource and can also carry query parameters and a fragment. The origin is the scheme, host, and port; a path and query do not change that origin. Query values are transmitted with the request target and may appear in logs, history, and shared links. A fragment is browser-side navigation state and is not included in the HTTP request target. The URL API parses and encodes components, avoiding hand-built strings whose escaping rules are easy to get wrong. A browser script should derive a relative request from the current origin, then choose only the query values the server expects. Same-origin restrictions govern script access to other origins; they are not an authorization system for the server's own endpoints.

Case study

A case-search page reads a term entered as 'pump & valve'. URLSearchParams encodes the ampersand as data, so the server receives one term instead of two accidental parameters. A section fragment can scroll to results without changing the case-search request. Changing the port changes the origin even when the host text stays the same. The example uses a relative path and browser location as its base; it does not embed an external host in code. An attacker may still edit every query field, so the server must validate the term and authorize any result independently.

Working contract

javascript
const searchTerm = document.querySelector("#case-search").value.trim();
if (searchTerm.length > 80) throw new RangeError("Search term is too long");
const target = new URL("/cases", window.location.origin);
target.searchParams.set("term", searchTerm);
window.location.assign(target.pathname + target.search);

Cost and tradeoffs

Constructing a query is O(L) in the total encoded input length. Parsing the resulting URL is O(U) in URL length; the browser supplies the parser rather than manual delimiter scans. A query is convenient for bookmarkable reads, but it is inappropriate for secrets or oversized state. Repeated parameters require an explicit policy: get returns one value, while getAll preserves the full list. The example's length check protects the user flow but does not replace server-side limits.

Common Mistakes

  • Do not put secrets in a query string.
  • Do not assume a fragment reaches the server with the request.
  • Do not build query strings by concatenating raw user text.
  • Do not use same-origin behavior as a substitute for server authorization.

Continue through the stack

HTML anchors: use href for navigation and stable fragment targets; HTML forms: choose GET for retrieval and POST for a state change; JavaScript Tutorial; HTTP requests: keep method, status, and body contracts separate.

Failure trace

A search term contains an ampersand and a hash mark. The client concatenates raw text into a URL; half the term becomes another parameter, and the rest is treated as a fragment that never reaches the server. Another developer stores an access token in the query for convenience, leaving it in browser history and logs. Use a URL parser and URLSearchParams, then validate the resulting field again on the server.

Verification

  • Submit a term containing ampersand, hash, plus, and non-ASCII text; compare the server's received value.
  • Change only the fragment and confirm the request target does not change.
  • Open the same host on a different port and confirm the browser treats it as another origin.

Decision note

A query is useful for bookmarkable reads and filters. It is a poor place for secrets or a large mutable draft. The server must treat every query value as caller-controlled even when client code generated it.

web-tech
web-development
Storage details