Jan Mikoláš
Glossary
Browser
A browser is neither a search engine nor the web page itself. It is a program that turns an address into a network connection, loads resources and creates the interface the user works with.
Short definition
A client program that assembles web resources into a usable interface.
After opening a URL, the browser looks up the required network information through DNS, establishes a connection, verifies the certificate for HTTPS and sends an HTTP request. It loads HTML, CSS, JavaScript, images, fonts and other resources from the response. The HTML parser creates a DOM from the document, CSS rules determine its presentation and JavaScript can further change the interface and its state.
The browser also manages cookies, history, the cache, bookmarks, permissions and web security boundaries. For example, the same-origin policy and CORS limit what a script from one page can read from another origin. These restrictions do not replace application authentication and authorization: the server must independently decide whether a specific request is permitted.
The problem it solves
It turns a web address into an interactive interface
A browser provides a common environment for reading content, completing forms and running more sophisticated web applications.
- opening a website or application from a URL and navigating between pages
- rendering HTML and CSS on screens of different sizes
- running JavaScript for interactions, forms and API communication
- working with cookies, the cache and user settings across repeat visits
- developer tools for inspecting network communication, the DOM, errors and performance
Practical example
From a product URL to displaying an order action
A user enters https://shop.example.cz/products/123. The browser resolves the hostname through DNS, establishes an HTTPS connection with the server and sends an HTTP request. The response contains the HTML for the product detail; the browser then progressively loads the CSS, an image and the JavaScript needed to select a variant, for example.
If the user submits a form, the browser transfers its data according to the defined HTTP flow. The server verifies the input, identity and permissions. The browser can display an error or confirmation, but the system must not rely on merely hiding a button or on JavaScript validation to protect a server operation.
How it works
The path from an address to a rendered page
Text diagram: URL → DNS → HTTPS and HTTP → HTML parser → DOM and CSS → rendering → JavaScript and interaction.
- The user opens a URL The address specifies the scheme, hostname, path and any parameters. The browser parses it and prepares the navigation.
- DNS finds the network destination A resolver returns information for the hostname, typically an IP address. The record may lead to a reverse proxy or infrastructure containing multiple servers.
- A secure connection is established For HTTPS, the browser verifies the validity and name of the certificate, then sends an HTTP request and receives a response.
- The document is parsed and rendered HTML becomes the DOM, CSS rules provide styling information, and the browser calculates the layout and visual representation of the page.
- Scripts add interactions JavaScript can respond to events or API data. It must handle errors, preserve accessibility and work with content securely.
Important considerations
A browser combines rendering, networking and security rules.
The resulting page combines resources, user settings, the network, and the behaviour of the specific browser.
Address bar and search
The address bar can open a URL or send text to a search engine. A search engine is a separate internet service, not a type of browser.
DOM and rendering
The DOM is a document tree created from HTML and modified by scripts. CSS creates a visual layout over it that need not match the original source file exactly.
Cookies and storage
Cookies have rules for their domain, path and security attributes. Other browser storage does not replace server-side checks of identity or permissions.
Cache
A browser can retain files and HTTP responses according to their headers. This performance improvement must not result in displaying improperly shared or stale user data.
Developer tools
The Network panel, inspector and console help inspect requests, the DOM, headers and errors. They do not, however, prove that a server operation cannot be invoked by another client.
Benefits and limitations
The standard web runtime is powerful, but it is not a trusted server boundary.
Benefits
- a standard environment for HTML, CSS, JavaScript and web APIs
- integrated navigation, history, caching, forms and developer tools
- protection for some web boundaries through origin rules, sandboxing and permissions
- access to a web application from different devices without installing a dedicated client
Risks and common mistakes
- confusing a browser with a search engine or the frontend with the entire program
- assuming the DOM always exactly matches the HTML that was sent
- relying on browser code to authorize a server action
- ignoring differences between devices, blocked scripts, extensions and slow connections
- treating private browsing mode as anonymity from the server, network or internet service provider
When its role is essential
Whenever a user accesses the web through standard web technologies.
The browser is a common client for simple content, administration interfaces, online stores and applications that work with APIs. A high-quality website accounts for the limitations of the user device: a small display, slow network, keyboard instead of a mouse, disabled JavaScript or browser extensions that block some resources.
Not every page needs to be a complex client application. Server-generated HTML, working links and forms provide a reliable foundation. JavaScript makes sense where it provides a genuinely better interaction and the application also handles errors, focus, state and server communication correctly.
What to consider
Prepare the website for real conditions on the client device.
A developer does not have complete control over the user's browser, but can build an interface that behaves predictably and securely.
- deliver semantic HTML and a working foundation for navigation or forms without depending on a script
- test mobile widths, keyboard navigation, focus, errors and a slower network
- insert untrusted content as text or sanitise it safely for the specific context
- configure HTTPS, cookies, HTTP caching and security headers correctly on the server
- do not transfer trust from the UI to the server: authentication, authorization and validation belong in the backend
Common questions
Web browsers in practice
Is a browser the same as a search engine?
No. A browser is a program for opening URLs, while a search engine is a service that searches web content. The address bar can use a search engine as one of its features.
Is the DOM the same as the HTML source file?
No. A browser creates the DOM from HTML, and JavaScript can then modify it. The DOM can therefore differ from the original server response.
Does the browser authorize the user?
No. A browser can send a cookie or token, but the server must verify the identity, permissions and resource context for every sensitive operation.
Is private browsing mode anonymous?
No. It usually limits the local history retained after the window is closed, but does not hide the visit from the website, network or internet service provider.
How I build web interfaces in practice
I design applications for real browsers, networks and users.
When working on PHP applications and integrations, I connect an accessible interface with the API and backend so the user receives a clear result even when something fails.