Getting Started with cURL: Talking to Servers from Your Terminal

What Happens When You Visit a Website?

Let me start with a simple question: what happens when you type "google.com" into your browser and press Enter?

Your browser does something pretty straightforward—it sends a message to Google's server that says, "Hey, give me your homepage." Google's server receives that message, processes it, and sends back another message containing the HTML, CSS, and JavaScript that make up the page you see.

This conversation happens instantly, invisibly, and your browser handles all the details for you. You click, you get a page. Simple.

But what if you're a programmer and you want to have that same conversation with a server—not through a browser, but through code? What if you want to:

Test if an API is working correctly
Download data from a website
Send information to a server
Debug what's actually being sent and received
Automate repetitive web requests

That's where cURL comes in.

What is cURL?

cURL (which stands for "Client URL") is a command-line tool that lets you send requests to servers and see their responses. It's like a browser, but instead of showing you a pretty webpage, it shows you the raw data that comes back.

Think of it this way:

Browser: "Show me the website in a nice, visual way"
cURL: "Show me exactly what the server sent back, word for word"

cURL is installed by default on most systems (Mac, Linux, and recent Windows versions), which makes it incredibly useful. You don't need to install libraries, write scripts, or set up environments. Open your terminal, type a command, and you're talking to servers.

In the simplest terms: cURL is a way to make your computer send messages to other computers over the internet, and see what they say back.

Why Programmers Need cURL

If browsers already exist and work great, why do programmers use cURL? Here are the real-world reasons:

1. Testing APIs When you're building or using an API (Application Programming Interface), you need to test if it's working. cURL lets you quickly send a request and see the response without writing code.

# Is this API endpoint working?
curl https://api.github.com/users/octocat

Within seconds, you know if it works and what data it returns.

2. Debugging Sometimes things break. A website isn't loading, or an API is returning errors. cURL helps you see exactly what's being sent and received, which makes debugging much easier.

3. Automation Need to download files regularly? Check if a service is up? Send data to a webhook? cURL can be scripted to do these tasks automatically.

4. Learning cURL is a fantastic teaching tool. It strips away all the visual polish and shows you what HTTP requests and responses actually look like. This helps you understand how the web really works.

5. Quick Experimentation Before writing code to interact with an API, you can use cURL to experiment. Try different requests, see what works, then translate that into your programming language of choice.

6. Server-Side Operations On servers (which often don't have graphical interfaces), cURL is sometimes the only way to make HTTP requests. No browser? No problem—you have cURL.

Your First cURL Request: Fetching a Webpage

Let's start with the absolute simplest thing you can do with cURL: fetch a webpage.

Open your terminal and type:

curl https://example.com

Press Enter. You should see something like this:

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">
    body {
        background-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", ...
    }
    </style>
</head>
<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents...</p>
</div>
</body>
</html>

Congratulations! You just made your first cURL request.

What happened?

You ran the curl command with a URL
cURL sent a request to example.com's server
The server responded with HTML (the raw code for the webpage)
cURL displayed that response in your terminal

This is exactly what your browser does, except your browser takes that HTML and renders it visually. cURL just shows you the raw data.

Understanding Request and Response

Every time you use cURL (or a browser, or any HTTP client), two things happen:

The Request

You send a request to a server. That request contains:

The URL: Where you want to connect (example.com)
The method: What you want to do (GET, POST, etc.)
Headers: Additional information (like what type of data you accept)
Body (optional): Data you're sending (for POST requests)

When you ran curl https://example.com, you sent a GET request, which means "get me the data at this URL."

The Response

The server sends a response back. That response contains:

Status code: Did the request succeed? (200 = success, 404 = not found, etc.)
Headers: Metadata about the response (content type, date, server info)
Body: The actual data (HTML, JSON, an image, etc.)

When example.com responded, it sent back the HTML you saw.

Let's see the complete picture with a slightly different command:

curl -i https://example.com

The -i flag means "include the response headers." Now you'll see:

HTTP/2 200 
content-type: text/html; charset=UTF-8
date: Sat, 31 Jan 2026 12:00:00 GMT
server: ECAcc (dcd/7D5A)
content-length: 1256

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
    ...

Breaking this down:

HTTP/2 200: The protocol version (HTTP/2) and status code (200 = success)
content-type: The server is sending back HTML
date: When the response was generated
server: What server software is running
content-length: How many bytes of data are in the response body
(blank line) Separates headers from body
<!doctype html>... The actual content starts here

Now you're seeing the complete conversation between your computer and the server.

Using cURL to Talk to APIs

Websites return HTML meant for browsers. But APIs (Application Programming Interfaces) return structured data meant for programs. Usually, that data is in JSON format.

Let's try fetching data from a real API. GitHub has a public API that doesn't require authentication for basic queries.

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

You'll see a response like this:

{
  "login": "torvalds",
  "id": 1024025,
  "node_id": "MDQ6VXNlcjEwMjQwMjU=",
  "avatar_url": "https://avatars.githubusercontent.com/u/1024025?v=4",
  "url": "https://api.github.com/users/torvalds",
  "name": "Linus Torvalds",
  "company": "Linux Foundation",
  "blog": "",
  "location": "Portland, OR",
  "bio": null,
  "public_repos": 6,
  "followers": 185000,
  "following": 0,
  "created_at": "2011-09-03T15:26:22Z"
}

This is JSON (JavaScript Object Notation)—a standard format for transmitting structured data. It's basically a set of key-value pairs that programs can easily parse.

You just fetched information about Linus Torvalds (creator of Linux) from GitHub's API, all from your terminal. No browser, no GUI, just a simple command.

Why is this useful?

Imagine you're building an application that displays GitHub user info. Before writing your actual code, you can use cURL to:

Verify the API endpoint works
See exactly what data it returns
Understand the structure of the response
Test different user names

Then, when you write your code (in Python, JavaScript, Go, whatever), you already know what to expect.

GET vs POST: Two Ways to Talk to Servers

When you communicate with a server, you use different "methods" depending on what you want to do. The two most common are GET and POST.

GET: Asking for Information

GET means "get me some data." You're requesting information from the server without changing anything.

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

This is a GET request. You're asking GitHub, "Give me information about this user." You're not creating, updating, or deleting anything—just reading.

When to use GET:

Fetching a webpage
Reading data from an API
Downloading a file
Searching for something

GET is the default method in cURL, so you don't need to specify it.

POST: Sending Information

POST means "here's some data I want you to process or store." You're sending information to the server.

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

Let's break down this command:

-X POST: Use the POST method
-H "Content-Type: application/json": Tell the server we're sending JSON data
-d '{"name": "Alice", "age": 30}': The data we're sending (in JSON format)
httpbin.org/post: A test endpoint that echoes back what you send

The response will show you what the server received:

{
  "json": {
    "name": "Alice",
    "age": 30
  },
  "headers": {
    "Content-Type": "application/json"
  },
  "url": "https://httpbin.org/post"
}

When to use POST:

Submitting a form
Creating a new resource (like a new user account)
Uploading a file
Sending data to be processed

Simple rule of thumb:

GET: "Show me something"
POST: "Here's something I want you to handle"

Common Mistakes Beginners Make with cURL

Let's address the mistakes people commonly make when they're just starting out. Don't worry—everyone makes these!

Mistake 1: Forgetting Quotes Around URLs with Special Characters

Wrong:

curl https://api.example.com/search?q=hello world

Problem: The space in "hello world" confuses your shell.

Right:

curl "https://api.example.com/search?q=hello world"

Lesson: Put quotes around URLs that contain spaces, special characters, or query parameters.

Mistake 2: Confusing Data Formats

Wrong:

curl -X POST https://httpbin.org/post \
  -d "name=Alice&age=30"

This sends form-encoded data (like an HTML form), but you probably wanted to send JSON.

Right (for JSON):

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

Lesson: Match your Content-Type header to the format of your data.

Mistake 3: Not Checking Status Codes

The problem:

curl https://api.example.com/nonexistent

You might see an error message in the response, but did you notice the request failed?

Better approach:

curl -i https://api.example.com/nonexistent

With -i, you'll see:

HTTP/2 404

The 404 status code tells you immediately that the resource wasn't found.

Lesson: Always check status codes. Use -i to see headers, or -w "%{http_code}\n" to display just the status code.

Mistake 4: Copy-Pasting Without Understanding

The problem: You find a complex cURL command online with 10 flags and paste it without understanding what it does.

curl -X POST -H "Authorization: Bearer abc123" -H "Content-Type: application/json" \
  --data-binary @file.json --compressed -v --retry 3 https://api.example.com/endpoint

Better approach: Start simple and add flags one at a time as you understand what they do.

# Start here
curl https://api.example.com/endpoint

# Add authentication
curl -H "Authorization: Bearer abc123" https://api.example.com/endpoint

# Add POST with data
curl -X POST -H "Authorization: Bearer abc123" -d '{"key":"value"}' https://api.example.com/endpoint

Lesson: Build up complexity gradually. Understand each flag before using it.

Mistake 5: Expecting cURL to Format JSON Automatically

What you see:

curl https://api.github.com/users/torvalds
{"login":"torvalds","id":1024025,"name":"Linus Torvalds",...}

It's all squished on one line, hard to read.

What you want: Pretty-printed, formatted JSON.

Solution: Pipe the output through a JSON formatter:

curl https://api.github.com/users/torvalds | python3 -m json.tool

Or if you have jq installed (a JSON processor):

curl https://api.github.com/users/torvalds | jq

Now you'll see:

{
  "login": "torvalds",
  "id": 1024025,
  "name": "Linus Torvalds",
  ...
}

Lesson: cURL returns raw data. Use other tools to format it for readability.

Mistake 6: Not Following Redirects

The problem: Some URLs redirect to other URLs. By default, cURL doesn't follow redirects.

curl http://github.com

You might get a response that says "Moved Permanently" instead of the actual page.

Solution: Use the -L flag to follow redirects:

curl -L http://github.com

Now cURL will automatically follow the redirect to https://github.com.

Lesson: If you get a 301 or 302 status code, use -L to follow redirects.

Building Your Confidence: Practical Exercises

Here are some simple exercises to get comfortable with cURL:

Exercise 1: Fetch a Web Page

curl https://example.com

What to notice: You're seeing the raw HTML that browsers render visually.

Exercise 2: See Response Headers

curl -i https://example.com

What to notice: The status code (200) and metadata about the response.

Exercise 3: Talk to a Real API

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

What to notice: You're getting JSON data back, not HTML.

Exercise 4: Send Data with POST

curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"message":"Hello from cURL"}'

What to notice: The server echoes back what you sent.

Exercise 5: Download a File

curl -O https://example.com/somefile.txt

What to notice: The -O flag saves the file instead of displaying it.

Exercise 6: Follow Redirects

curl -L http://github.com

What to notice: Without -L, you'd just see the redirect. With it, you get the final page.

Where cURL Fits in Backend Development

Understanding where cURL fits in the bigger picture helps you see why it's so valuable:

┌──────────────────────────────────────────────┐
│           Your Development Process           │
└──────────────────────────────────────────────┘

1. Planning Phase
   ├─ Read API documentation
   └─ Understand what endpoints exist

2. Experimentation Phase ← cURL shines here!
   ├─ Test API endpoints with cURL
   ├─ See exactly what data comes back
   ├─ Try different parameters
   └─ Confirm authentication works

3. Implementation Phase
   ├─ Write actual code (Python, JS, etc.)
   ├─ Use knowledge from cURL experiments
   └─ Handle edge cases you discovered

4. Debugging Phase ← cURL helps here too!
   ├─ Request not working? Try it with cURL
   ├─ See raw request/response
   └─ Isolate whether problem is your code or the API

5. Production Phase
   ├─ Monitor endpoints with cURL
   ├─ Automate health checks
   └─ Quick debugging in production

The workflow:

Before writing code: Use cURL to explore and understand the API
While writing code: Reference your cURL experiments to know what to expect
When debugging: Use cURL to isolate problems
In production: Use cURL for monitoring and quick checks

Visualizing the Request Flow

Here's what happens when you use cURL vs a browser:

Browser Request Flow

You click link
    ↓
Browser builds HTTP request
    ↓
Browser sends request to server
    ↓
Server processes request
    ↓
Server sends HTTP response
    ↓
Browser receives HTML/CSS/JS
    ↓
Browser renders beautiful page
    ↓
You see pretty website

cURL Request Flow

You type curl command
    ↓
cURL builds HTTP request
    ↓
cURL sends request to server
    ↓
Server processes request (same as browser!)
    ↓
Server sends HTTP response (same as browser!)
    ↓
cURL receives HTML/JSON/data
    ↓
cURL displays raw response
    ↓
You see exactly what was sent

The key difference: Everything up to receiving the response is the same. The only difference is what happens to that response. Browsers render it; cURL shows it raw.

This is why cURL is so valuable for understanding HTTP—it strips away all the visual polish and shows you what's really happening.

What We've Learned

Let's recap the essentials:

cURL is a tool for sending HTTP requests from the terminal. It's like a browser, but for raw data instead of pretty pages.
Why it matters: Testing APIs, debugging, automation, learning, and quick experimentation.
Basic syntax: curl [URL] gets you started. Add flags to customize behavior.
Request and response: Every HTTP interaction has a request (what you send) and a response (what comes back).
GET vs POST: GET retrieves data, POST sends data.
Common flags:
- -i shows headers
- -X POST specifies the method
- -H adds headers
- -d sends data
- -L follows redirects
- -O downloads files
Start simple: Don't overwhelm yourself with flags. Learn one thing at a time.
Practice builds confidence: The more you use cURL, the more natural it becomes.

Next Steps

Now that you understand the basics, here's how to continue learning:

Practice regularly:

Try making requests to public APIs
Experiment with different flags
Use cURL when building your own projects

Learn more flags as you need them:

-v for verbose output (see everything)
-u user:pass for basic authentication
--data-binary for sending binary data
-F for multipart form data (file uploads)

Explore real APIs:

GitHub API: https://api.github.com
JSONPlaceholder (fake API for testing): https://jsonplaceholder.typicode.com

Combine with other tools:

Use jq to process JSON responses
Pipe output to grep to search for specific content
Save responses to files for analysis

Final Thoughts

cURL is one of those tools that seems simple on the surface—it just fetches URLs, right? But it's deceptively powerful. It's a diagnostic tool, a testing tool, a learning tool, and an automation tool all rolled into one simple command.

The best way to learn cURL is to use it. Start with simple requests. Get comfortable seeing raw responses. Gradually add complexity as you need it. Before long, you'll find yourself reaching for cURL whenever you need to talk to a server, debug an API, or understand how an HTTP request works.

And here's the beautiful part: once you understand cURL, you understand HTTP. And once you understand HTTP, you understand how the entire web works. That knowledge will serve you well throughout your entire programming career.

So open your terminal, type curl https://example.com, and start exploring. The servers of the internet are waiting to talk to you.

Getting Started with cURL: Talking to Servers from Your Terminal

What Happens When You Visit a Website?

What is cURL?

Why Programmers Need cURL

Your First cURL Request: Fetching a Webpage

Understanding Request and Response

The Request

The Response

Using cURL to Talk to APIs

GET vs POST: Two Ways to Talk to Servers

GET: Asking for Information

POST: Sending Information

Common Mistakes Beginners Make with cURL

Mistake 1: Forgetting Quotes Around URLs with Special Characters

Mistake 2: Confusing Data Formats

Mistake 3: Not Checking Status Codes

Mistake 4: Copy-Pasting Without Understanding

Mistake 5: Expecting cURL to Format JSON Automatically

Mistake 6: Not Following Redirects

Building Your Confidence: Practical Exercises

Exercise 1: Fetch a Web Page

Exercise 2: See Response Headers

Exercise 3: Talk to a Real API

Exercise 4: Send Data with POST

Exercise 5: Download a File

Exercise 6: Follow Redirects

Where cURL Fits in Backend Development

Visualizing the Request Flow

Browser Request Flow

cURL Request Flow

What We've Learned

Next Steps

Final Thoughts

Comments

More from this blog

JWT Authentication in Node.js Explained Simply

Sessions vs JWT vs Cookies: Understanding Authentication Approaches

REST API Design Made Simple with Express.js

Handling File Uploads in Express with Multer

Storing Uploaded Files and Serving Them in Express

Command Palette

What Happens When You Visit a Website?

What is cURL?

Why Programmers Need cURL

Your First cURL Request: Fetching a Webpage

Understanding Request and Response

The Request

The Response

Using cURL to Talk to APIs

GET vs POST: Two Ways to Talk to Servers

GET: Asking for Information

POST: Sending Information

Common Mistakes Beginners Make with cURL

Mistake 1: Forgetting Quotes Around URLs with Special Characters

Mistake 2: Confusing Data Formats

Mistake 3: Not Checking Status Codes

Mistake 4: Copy-Pasting Without Understanding

Mistake 5: Expecting cURL to Format JSON Automatically

Mistake 6: Not Following Redirects

Building Your Confidence: Practical Exercises

Exercise 1: Fetch a Web Page

Exercise 2: See Response Headers

Exercise 3: Talk to a Real API

Exercise 4: Send Data with POST

Exercise 5: Download a File

Exercise 6: Follow Redirects

Where cURL Fits in Backend Development

Visualizing the Request Flow

Browser Request Flow

cURL Request Flow

What We've Learned

Next Steps

Final Thoughts

Comments

More from this blog