After you enter a web address, the browser identifies the destination, usually resolves the domain name through DNS, establishes a network connection, secures it with TLS for HTTPS, sends an HTTP request, receives page resources, and turns those resources into the page you see.
Pressing Enter in a browser starts a chain of jobs that usually finishes quickly enough to feel like one action. The browser first interprets the URL: it identifies the scheme, such as HTTPS, the domain name, and any path that points to a particular resource. It can also check caches and previously stored connection information before deciding which network work is actually necessary.
A domain name is convenient for people, but the network ultimately needs an address it can route to. DNS provides that translation. If the needed result is not already cached, a DNS lookup helps the browser obtain an IP address for the server or service handling the site. Modern websites may use content-delivery networks, load balancers, and other infrastructure, so the IP address is not necessarily a single physical machine permanently assigned to that domain.
Once a destination is known, the browser needs a connection. Traditional HTTP connections commonly use TCP, while newer HTTP versions can use other transport arrangements, but the purpose is similar: create a reliable path for exchanging web data. For an HTTPS site, a TLS handshake also establishes encrypted communication and lets the browser authenticate the server using its certificate. HTTPS protects the confidentiality and integrity of data while it travels between the browser and server.
The browser can then send an HTTP request describing the resource it wants. The server responds with a status and data, often beginning with an HTML document. That HTML is rarely the whole page. It can reference style sheets, JavaScript, fonts, images, video, and data from additional endpoints. The browser may therefore make many more requests, sometimes to several hostnames, while reusing connections and caches when possible.
Receiving the files still does not produce the finished screen. The browser parses HTML into a document structure, processes CSS to determine how elements should look, runs JavaScript where required, calculates layout, and paints pixels to the display. Some resources can be fetched in parallel, while scripts or slow network responses can delay later work. The page can become visible before every background request has finished.
So the trip from URL to webpage is not one request followed by one picture. It is a coordinated sequence involving naming, routing, security, HTTP, parsing, layout, scripting, and rendering. Caching and modern protocols can skip or accelerate parts of that sequence, which is one reason the same page may load much faster on a repeat visit than on the first one.