Getting Started with cURL: How to Talk to a Server From Your Terminal

If you've ever opened your browser's Network tab, seen a wall of requests flying back and forth, and wondered "how do people do this stuff without a browser?" — this article is for you.

By the end of this post, you'll understand what cURL is, why almost every backend developer keeps it open in a terminal tab, and you'll have made your very first request. No jargon-heavy detours, no 40-flag cheat sheets. Just the basics, explained the way they should have been explained to you the first time.

---

First, What Is a Server — and Why Do We Even Need to Talk to It?

Imagine a restaurant. You (the customer) don't walk into the kitchen and cook your own food. Instead, you tell a waiter what you want, the waiter carries that request to the kitchen, the kitchen prepares it, and the waiter brings the result back to your table.

A server is the kitchen. It's a computer somewhere (maybe down the hall, maybe on the other side of the planet) that stores data, runs logic, and hands back results when someone asks nicely.

Every time you open a website, check a weather app, or log into an account, your device is sending a request to a server and waiting for a response. Your browser has been playing waiter for you this whole time — quietly making these requests and rendering the results as a webpage so you never had to think about the conversation happening underneath.

cURL lets you become the waiter yourself.

What Is cURL, in Very Simple Terms

cURL (pronounced "curl", short for Client URL) is a command-line tool that lets you send requests to a server directly from your terminal, without needing a browser at all.

Think of it as a way to type out a message, address it to a server, hit send, and read the reply — all in plain text, right where you're already writing code.

curl https://example.com

That one line does exactly what your browser does when you type a URL into the address bar and hit Enter — except instead of rendering a pretty page, cURL just shows you the raw response.

Why Programmers Need cURL

You might be thinking: "I already have a browser. Why do I need this?"

Here's why cURL earns a permanent spot in every backend developer's toolkit:

• Testing APIs without building a UI first. You can check if your backend endpoint works before a single line of frontend code exists.
• Debugging in the exact environment your app runs in. Servers, CI pipelines, and Docker containers usually don't have browsers — but they almost always have cURL.
• Precise control. You decide exactly what headers, data, and method get sent — nothing extra, nothing hidden.
• Speed. No clicking through UI panels. Just one line in the terminal and you have your answer.
• It's everywhere. cURL ships with most operating systems and is often the first tool used to verify "is my server even reachable?"

In short: cURL is how developers have a direct, no-nonsense conversation with a server.

The Big Picture: cURL → Server → Response

 ┌────────────┐        request         ┌────────────┐
 │            │ ─────────────────────► │            │
 │   cURL     │                        │   Server   │
 │ (terminal) │ ◄───────────────────── │            │
 └────────────┘        response        └────────────┘

That's really the whole story. You send something, the server processes it, and it sends something back. Everything else in this post is just filling in the details of that arrow.

Making Your First Request Using cURL

Let's keep this as simple as physically possible. Open your terminal (cURL comes pre-installed on macOS and most Linux distributions; on Windows 10+, it's built into PowerShell/CMD too) and type:

curl https://api.github.com

Hit Enter. You'll see a block of text scroll by — that's the server's response, written in a format called JSON. You just made your first request without touching a browser.

Want to see a normal webpage instead of JSON? Try:

curl https://example.com

You'll see raw HTML — the same HTML your browser would normally turn into a nicely styled page for you.

Understanding Request and Response

Every time you use cURL (or a browser, or an app), you're really sending a package with a few key parts, and getting a package back with a few key parts.

A request typically has:

• A URL — where you're sending it (https://api.github.com/users/octocat)
• A method — what kind of action you want (more on this below)
• Headers — extra information about the request, like what format you want the response in
• A body (sometimes) — data you're sending along, like a new user's name and email

A response typically has:

• A status code — a short number telling you what happened (200 means success, 404 means "not found", 500 means the server had a problem)
• Headers — metadata about the response
• A body — the actual data or content you asked for

REQUEST                          RESPONSE
--------                         --------
Method:  GET                     Status:  200 OK
URL:     /users/octocat          Headers: Content-Type: application/json
Headers: Accept: application/json
Body:    (none for GET)          Body:    { "login": "octocat", ... }

You can see the status code and headers directly with cURL using the -i flag:

curl -i https://api.github.com

This is the single most useful habit to build early: whenever something goes wrong, check the status code first. It tells you, in one number, roughly whose fault it is — yours, or the server's.

Browser Request vs cURL Request (Conceptually)

A browser and cURL are doing the same fundamental thing — sending a request and receiving a response — they just differ in what happens to that response afterward.

        You type a URL
               │
               ▼
      ┌──────────────────┐
      │   Browser         │──► sends request ──► Server
      │  (renders result  │◄── gets response ───
      │   as a webpage)   │
      └──────────────────┘

      ┌──────────────────┐
      │   cURL             │──► sends request ──► Server
      │ (prints raw result │◄── gets response ───
      │   to terminal)     │
      └──────────────────┘

A browser takes the response and paints it as buttons, images, and text. cURL takes the same response and just prints it, raw, exactly as the server sent it. That's the whole difference — and it's precisely why cURL is so useful for developers: you see the real data, with nothing hidden behind styling.

Using cURL to Talk to APIs

Most real-world use of cURL isn't fetching webpages — it's talking to APIs (Application Programming Interfaces), which are servers designed specifically to exchange data, not pretty pages.

To keep things beginner-friendly, let's focus on just the two methods you'll use 90% of the time starting out:

GET — "Give me some data"

GET is for reading information. It's the default method cURL uses if you don't specify one.

curl https://api.github.com/users/octocat

This asks the GitHub API for public information about the user octocat and returns it as JSON.

POST — "Here's some data, please save it"

POST is for sending information — creating something new, submitting a form, logging in, and so on.

curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"name": "Ada", "role": "Developer"}'

Let's break that down:

• -X POST tells cURL which method to use
• -H "Content-Type: application/json" tells the server "the data I'm sending is JSON"
• -d '...' is the actual data (the request body) you're sending

That's genuinely 90% of what you need to start exploring APIs confidently. GET to read, POST to send — everything else can wait until you actually need it.

Where cURL Fits in Backend Development

 Frontend            cURL (you, testing)         Backend API           Database
 ┌────────┐          ┌────────────────┐          ┌───────────┐        ┌──────────┐
 │  App /  │          │  Terminal       │          │  Server   │        │  Data     │
 │  Browser│          │  request/       │ ───────► │  (routes, │ ─────► │  storage  │
 │         │          │  response check │ ◄─────── │  logic)   │ ◄───── │           │
 └────────┘          └────────────────┘          └───────────┘        └──────────┘

Before your frontend ever touches an API, developers usually verify it with cURL first — is the endpoint live, does it accept the right data, does it return what's expected. It becomes your first line of defense against bugs, long before a UI is involved.

Common Mistakes Beginners Make With cURL

A few small stumbles trip up almost everyone early on — here's how to skip them:

1. Forgetting quotes around JSON data. Your shell can misinterpret special characters like {, }, and " if they aren't wrapped properly. Always wrap your -d payload in single quotes.

2. Sending JSON without the Content-Type header. If you send a JSON body but forget -H "Content-Type: application/json", many servers won't parse it correctly — and you'll get a confusing error that has nothing to do with your actual data.

3. Assuming GET when you meant POST (or vice versa). cURL defaults to GET. If you're trying to create or send data, you must explicitly add -X POST.

4. Ignoring the status code. A response with no visible error doesn't mean it worked. Always check the status with -i — a 404 or 500 buried in a big response body is easy to miss otherwise.

5. Not realizing HTTPS vs HTTP matters. Some servers reject plain http:// and expect https://. If your request silently fails, double-check the protocol.

6. Testing against the wrong environment. It's easy to accidentally hit a production API when you meant to test locally (localhost:3000). Always double-check your URL before running commands that send or modify data.

Wrapping Up

cURL isn't complicated — it just looks unfamiliar the first time you see it. At its core, it's nothing more than a way to send a message to a server and read what comes back, the exact same conversation your browser has been having on your behalf all along.

Start with plain GET requests. Get comfortable reading status codes. Then move on to POST. Everything else — headers, authentication tokens, file uploads — builds naturally on this same request-and-response foundation.

The next time someone says "just cURL the endpoint," you'll know exactly what they mean — and exactly how to do it.

---

Found this helpful? Try running a few of these commands yourself right now — the best way to get comfortable with cURL is to break something with it and figure out why.