What Happens When You Type a URL?

A URL, or Uniform Resource Locator, identifies a resource and describes how to reach it. Web URLs commonly use the HTTP or HTTPS scheme, but URLs can point to documents, images, API endpoints, downloads, media, or other resources rather than only complete webpages.

Consider https://www.example.com:443/products/cameras?sort=price#reviews. The scheme is https. The hostname is www.example.com. Port 443 is explicitly shown, although it is normally omitted because it is the default for HTTPS. The path is /products/cameras, the query is sort=price, and the fragment is reviews.

These components do different jobs. The scheme selects the general access rules. DNS normally resolves the hostname, not the entire URL. The path and query help the server or application identify the requested representation. The fragment identifies a location or state inside the returned document and is handled by the browser; it is not included in the HTTP request target.

A domain name and a URL are therefore not the same thing. example.com is a domain name. https://example.com/account?tab=security is a URL containing that domain plus a scheme, path, and query. One domain can support many URLs, and the same URL can return different representations over time or according to request context.

Reserved characters have structural meaning, so data placed inside a URL sometimes needs percent-encoding. A space, for example, cannot simply appear everywhere as a literal space. Encoding preserves the distinction between data and separators, but it does not encrypt the URL or make sensitive information private.

This explainer follows a normal top-level HTTPS navigation. Real browsers optimize, overlap, reuse, or skip stages depending on cache state, previous connections, service workers, redirects, security policy, and the protocol selected. The journey is a pipeline, not one rigid sequence that every visit repeats from zero.

When you press Enter, the browser first decides how to interpret the address-bar input. If it recognizes a URL or hostname, it prepares a navigation. If the text looks like an ordinary phrase, many browsers send it to the configured search engine instead. That search path is different from directly opening a known URL.

For a URL, the browser parses the scheme, authority, hostname, port, path, query, and fragment according to URL rules. It normalizes some details and determines the origin, which is primarily the combination of scheme, hostname, and port. Origin boundaries later affect cookies, storage, script access, permissions, and cross-origin security rules.

The browser then applies relevant navigation and security policy. A remembered or preloaded HSTS rule can upgrade an HTTP address to HTTPS before an insecure request is made. Enterprise settings, extensions, parental controls, safe-browsing systems, or a configured proxy may also influence the route or block the navigation.

Local state can eliminate work. The HTTP cache may contain a reusable document, redirects can be cached, and an existing connection might still be available. A service worker installed for the site may intercept eligible requests and respond from its own cache or fetch strategy. The browser still follows freshness and security rules; finding a file locally does not automatically mean it can reuse it without validation.

If the navigation changes only the fragment on the current document, the browser may scroll or update history without requesting the page again. For a normal new HTTPS navigation, it must identify a network destination unless an existing connection, cache entry, or intermediary already satisfies the request.

Modern browsers divide this work across several processes. The browser process manages high-level navigation and security decisions, while network and renderer processes handle other responsibilities. The exact architecture varies, but the page's untrusted code does not receive unrestricted control over the navigation pipeline.

A browser cannot route a packet using a hostname alone. It needs an address and, in some modern configurations, additional service information. DNS supplies records associated with the hostname, such as A records for IPv4 addresses and AAAA records for IPv6 addresses.

The lookup often finishes from cache. The browser, operating system, home network, or recursive DNS resolver may already hold an unexpired answer. If not, the recursive resolver follows the DNS hierarchy: a root server points toward the relevant top-level-domain servers, those servers identify the domain's authoritative servers, and an authoritative server supplies the requested record.

DNS can return more than one address. Large services distribute traffic across data centers and content-delivery networks, so the answer may vary by location, network, resolver, service health, or provider design. The address may belong to a CDN edge, reverse proxy, or load balancer rather than the computer that ultimately runs the application.

The browser or operating system can attempt suitable IPv6 and IPv4 candidates without waiting unnecessarily for one family to fail. Current systems may also use HTTPS or SVCB records to learn supported service endpoints or connection information, though deployment and browser behavior vary.

DNS over HTTPS and DNS over TLS can encrypt the path between a device and its recursive resolver. DNSSEC can let a validating resolver verify signed DNS data. These mechanisms protect different parts of the lookup: encrypted DNS does not make browsing anonymous, and DNSSEC does not encrypt the query.

When DNS fails, the web server may be perfectly healthy but unreachable by name. Incorrect records, expired cache entries, broken delegation, unavailable resolvers, network filtering, or DNSSEC validation failures can all stop the journey before an HTTP request is sent.

With candidate addresses available, the browser can establish a connection to the selected endpoint. The exact handshakes depend on the HTTP version and what the browser and server support.

HTTP/1.1 and HTTP/2 over HTTPS commonly run over TCP. TCP establishes a reliable, ordered byte stream and manages retransmission, flow control, and congestion control. The browser then performs a TLS handshake over that transport. During the handshake, the parties agree on cryptographic parameters, the server presents a certificate chain for the hostname, and they derive session keys.

The browser checks whether the certificate is valid for the requested hostname, within its validity period, and linked to a trusted certification authority under the browser's policy. A successful check normally authenticates control of the named service and protects the connection in transit. It does not prove that every statement, download, seller, or business practice on the site is trustworthy.

HTTP/3 follows a different path. It runs over QUIC, which uses UDP as its underlying datagram service and integrates TLS 1.3 into the QUIC handshake. QUIC provides encrypted, reliable streams and avoids some connection-level blocking that can affect multiple HTTP/2 streams when a TCP packet is lost.

Protocol negotiation lets the endpoints select a mutually supported HTTP version. Browsers can remember or discover that a service supports HTTP/3, but they also need fallbacks because UDP may be blocked or the endpoint may not support QUIC. The visible URL remains https:// in each case; users usually do not choose the transport manually.

Repeat visits can be faster because the browser may reuse an open connection or resume a previous secure session. Network changes, certificate problems, firewall policy, packet loss, distance, and server load can all add delay before the first HTTP request is ready to travel.

The browser now creates an HTTP request. A normal address-bar navigation usually uses GET because it is retrieving a representation. The request target contains the path and query, while the hostname is represented through the Host header in HTTP/1.1 or the equivalent authority information in newer versions.

Headers describe the request and the browser's capabilities. They can include accepted media and compression formats, language preferences, cache validators, referrer information, fetch metadata, and eligible cookies. The exact set depends on browser policy, privacy settings, site context, and protocol version.

Cookies are not sent to every site. Their domain, path, Secure, SameSite, and expiry rules must match, and browser privacy protections may further restrict cross-site cookies. A session cookie can allow the server to associate the request with an existing sign-in, but the browser does not send passwords again with every page request.

Request bodies are common with methods such as POST or PUT, but a top-level GET navigation usually has no body. Sensitive values should not be placed in query strings because URLs can appear in browser history, server logs, analytics, copied links, and referrer data under applicable policy. HTTPS protects the request while it travels, not every place the URL may later be recorded.

The request passes through the selected transport and across multiple networks. It may reach a forward proxy, CDN edge, security gateway, reverse proxy, or load balancer before the application. These intermediaries can terminate the connection, enforce policy, serve a cached response, or forward a new request deeper into the service.

HTTP supports multiplexing in HTTP/2 and HTTP/3, allowing multiple request and response streams over one connection. Browsers also prioritize work, so requests for the document, styles, scripts, fonts, and images do not necessarily travel in the order they appear visually on the page.

The first responding system may be an edge server rather than the origin application. A CDN can return a fresh cached representation immediately, reducing distance and origin load. It can also handle TLS, compression, traffic filtering, and routing before forwarding a cache miss.

A reverse proxy or load balancer selects an available backend according to configuration and service health. Middleware may attach request identifiers, apply rate limits, check authentication tokens, enforce redirects, or reject malformed input. None of these layers is required for a simple site, but large services commonly use several.

Static hosting can map the request to a prepared HTML file or another stored asset. Dynamic applications run code. They may check a session, confirm authorization, read caches, query a database, call internal or external services, calculate a result, and assemble HTML or structured data.

Server-side rendering can generate HTML for the requested route before returning it. Static generation can prepare that HTML earlier during a build. Client-rendered applications may send a smaller document shell and rely on JavaScript to request data later. Many production sites mix these strategies rather than fitting one label.

Server processing can fail or redirect. A moved route may return a 301 or 308 permanent redirect, while a temporary redirect may use 302, 303, or 307 depending on the intended method behavior. Authentication may lead to a sign-in page, and an overloaded dependency can delay or prevent the response.

Good server design validates input and authorization on the server even if the browser already checked a form. It also sets suitable cache, content, cookie, and security headers. Client-side controls improve experience, but they cannot be the final security boundary because a requester can construct HTTP messages without using the site's interface.

An HTTP response contains a status code, fields called headers, and often a body. A 200 response indicates successful handling, 404 means the selected resource was not found, and 500 represents an unexpected server-side failure. Other status codes redirect, authorize, validate caches, or describe different outcomes.

Response headers tell the browser how to interpret and handle the body. Content-Type identifies the media type, Content-Encoding can describe compression, Cache-Control defines reuse rules, Content-Security-Policy can restrict resource loading and script execution, and Set-Cookie can create or update eligible cookies.

If the browser already has a stale cached representation, it may send a validator such as an entity tag. The server can respond with 304 Not Modified, allowing the browser to reuse its stored body instead of downloading it again. A fresh cache entry can be reused without contacting the server, depending on its directives and browser policy.

The body can arrive progressively. A browser does not always wait for the entire HTML document before beginning to parse it. Servers and frameworks may stream markup, and network protocols divide data into units that are delivered and processed over time.

While parsing HTML, the browser discovers references to style sheets, scripts, fonts, images, frames, and other resources. Each can require another cache decision and HTTP request, sometimes to a different hostname with its own DNS and connection work. A preload scanner can identify some resources before the main parser reaches them.

Compression, caching, CDN placement, server response time, resource size, protocol reuse, and request priority all affect loading. A fast initial HTML response does not guarantee a fast experience if the page then performs large transfers or expensive browser work.

The browser turns the response into a visual, accessible, and interactive document. As it parses HTML, it builds the Document Object Model, or DOM. The DOM represents elements, text, attributes, and relationships that scripts and browser systems can inspect or change.

CSS is parsed into rules that participate in the cascade. The browser combines document structure with applicable styles, determines which boxes are rendered, and calculates their sizes and positions during layout. It then records drawing operations during paint and combines appropriate layers during compositing to produce pixels on the screen.

These stages can repeat. A newly loaded font can change text measurements, an image without reserved dimensions can move nearby content, and JavaScript can add or remove elements. Browsers try to update only what is necessary, but complex style changes and long scripts can still delay responsiveness or create visible movement.

JavaScript execution interacts with parsing. A classic script without defer or async can pause the HTML parser while it is fetched and executed because it may modify the document. Deferred, asynchronous, and module scripts have different scheduling rules. The browser's main thread also handles many user-interface tasks, so long-running code can prevent clicks and typing from being processed promptly.

Server-rendered application HTML may appear before its client JavaScript is ready. Frameworks often hydrate existing markup by attaching state and event behavior. Other applications render most of the interface in the browser after scripts and data arrive. Seeing content and being able to interact with every control are therefore separate milestones.

After the first view becomes usable, the page can keep working. Scrolling may trigger lazy-loaded images, clicks may request API data, real-time connections can deliver updates, and a service worker can support offline or background strategies where the platform permits. Origin rules, CORS, sandboxing, permissions, and content policies continue to constrain what code may access.

Developer tools expose this journey as a network waterfall, timing data, console messages, document structure, styles, storage, accessibility information, and performance traces. When a page feels slow, the cause may be DNS or connection delay, server waiting, large resources, cache misses, script execution, layout, painting, or third-party code—not simply “the Internet.”