A client, in computing, is a program that requests something from another program called a server, then uses whatever comes back. The web browser you are reading this in is a client: it asked a server for this page, the server sent it, and the browser displayed it. That request-and-response pattern is the heart of the client-server model, and it describes most of how the internet actually works. A client always starts the conversation; the server waits and answers. Understanding which side is which clears up a surprising amount of confusion about how apps and websites operate.
How the client-server model works
The model has two roles. The client initiates a request, the server processes it and sends a response. Picture ordering at a counter: you, the client, place an order; the kitchen, the server, prepares it and hands it back. The client does not need to know how the kitchen works, only how to ask and what to expect.
On the web, this happens over HTTP. Your browser sends an HTTP request to a server identified by a URL, the server runs whatever logic it needs, and it returns HTML, data, or a file. The same shape repeats for a mobile app talking to an API, a database tool querying a database, or one microservice calling another. If you want the other half of the picture, the companion guide on what a server is covers the responding side in detail.
Types of clients
Clients are not all browsers. The term covers any software that makes requests.
| Client type |
Example |
Notes |
| Web client |
A browser like Chrome or Firefox |
Requests and renders web pages |
| Mobile or desktop app |
A banking app, an email app |
Talks to a backend API |
| Command-line client |
A tool that hits a REST API |
No graphical interface |
| Another server |
A service calling a payment API |
A server can be a client too |
That last row matters: client and server are roles, not fixed identities. A program can be a server to one party and a client to another at the same time.
Thin clients vs thick clients
A common distinction is how much work the client does on its own.
A thin client keeps most logic and data on the server and does little beyond displaying results, which makes it lightweight and easy to update centrally. A thick, or fat, client does more processing locally, which can feel faster and work offline but is harder to keep consistent across devices. Most modern web apps sit somewhere in between, doing meaningful work in the browser while relying on the server for data and security.
When a client talks to a server, it usually does so through an interface the server exposes. To understand that contract, read what a REST API is, since that is the most common way clients and servers communicate today.
Common misconceptions
- The client is the device. Not quite. The client is the requesting program; the device just runs it.
- Clients are always browsers. Apps, scripts, and other servers are clients too whenever they make requests.
- The server always knows more. The server holds shared data and rules, but a client can hold plenty of its own state and logic.
- Client and server are fixed labels. They are roles in a given exchange, and one program can switch between them.
FAQ
What is a client in simple terms?
A program that asks a server for something and uses the response, like a browser requesting a web page.
What is the difference between a client and a server?
The client makes the request and the server answers it. They are roles in a conversation, not necessarily different machines.
Is my phone a client?
Your phone is a device, but the apps and browser running on it act as clients when they request data from servers.
What is a thin client?
A client that does little processing itself and relies on the server for most logic and data, which makes it light and easy to manage centrally.
Where to go next
What is a server, What is a REST API, and What is a web browser.