Client

In short: A device or program that requests services or data from a server — the counterpart to the server in the client-server model.

In more detail: Examples: a browser loading a web page from a web server, or an email program retrieving messages from a mail server. A device can, depending on context, be both a client and a server at the same time (e.g. in peer-to-peer systems).

In Depth

The division of roles in the client-server model

The client-server model describes a fundamental division of roles, not necessarily physically separate hardware: the client initiates a request, the server passively waits for such requests and answers (response) — this asymmetry is the core of the model, regardless of whether client and server are in the same room or on different continents communicating over the internet. A browser is just one example among many: a mobile app fetching data from a REST API, a mail client retrieving messages from a mail server, or a game synchronising its save state with a game server, all follow the same basic pattern.

Thick vs. thin clients

An important distinction is that between “thick” clients (fat/thick client — a lot of logic and processing runs locally on the client, the server mainly delivers raw data, e.g. classic desktop software) and “thin” clients (thin client — almost all logic runs server-side, the client only displays the result, e.g. a simple server-side-rendered web page). Modern web applications often sit somewhere in between, since a lot of logic now runs directly in the browser via JavaScript.

When something is both client and server at once

It’s important to distinguish this from the role of “peer” in peer-to-peer networks (e.g. in some file-sharing protocols), where every participant acts as both client AND server at once — there’s no fixed hierarchy, everyone can both send and answer requests. Even within a typical web architecture, the division of roles is often multi-layered: a web server is a server from the browser’s point of view, but itself acts as a client when it requests data from a database or another backend service — the same machine can therefore take on both roles at once, depending on which direction you’re looking from.

Client-side hardware

Colloquially, “client” is also used for the physical end device itself that a user works on — from desktop PCs to laptops to smartphones and tablets. These devices typically need to be considerably less powerful than the associated server, since they usually only serve a single user at a time, while a server often serves thousands of clients in parallel.

Client-side vs. server-side validation

An important security principle: client-side logic (e.g. input checks in a form) primarily serves usability — fast feedback without a server round trip — but must never be the only control, since the client is fundamentally considered untrustworthy. Every client can be manipulated (e.g. via developer tools in the browser or a modified app), which is why security-critical checks (authorisation, prices, quantity limits) always have to be additionally enforced server-side — a purely client-side check is, at best, a convenience, never a real protective mechanism.

Types of client applications

Besides the classic web client, there are native clients (standalone apps for a specific operating system, e.g. a desktop or smartphone app) and hybrid approaches (web technologies in a natively packaged app, e.g. via Electron or Cordova). Native clients usually offer better performance and deeper access to system functions (camera, notifications, file system), but require separate development per platform, while web clients work cross-platform from a single codebase, but remain limited by the browser’s feature set.

See also: Server, End device, Browser