Skip to main content

Command Palette

Search for a command to run...

Getting Started with cURL: The Terminal’s Browser

Leave the graphical interface behind. Learn how to talk directly to servers and APIs from your command line.

Published
6 min read
Getting Started with cURL: The Terminal’s Browser
H
CS Graduate | Technical Writing | Software development | 20K+ impressions

Before you write a single line of backend code or fetch data for a frontend component, you need to understand what a server actually is.

In the simplest terms, a server is just a computer sitting somewhere in a cold room, waiting for a message. When it receives a message, it reads it, decides what to do, and sends a message back.

Usually, your web browser handles this conversation for you. You type a URL, and Chrome or Firefox sends the message, gets the response, and paints a beautiful webpage full of colors, images, and fonts.

Learn how this happens in this blog -

But as a developer, you often don't care about the paint. You don't want the browser to render a UI. You just want to see the raw data the server is sending back, or you want to test an API you just built. You need a way to talk to the server directly, stripping away all the graphical translation.

You need cURL.


What is cURL?

cURL (Client URL) is a command-line tool that allows you to send and receive data across a network.

Instead of typing a web address into an address bar and hitting Enter, you type a command into your terminal. cURL takes your request, hands it to the server, and dumps the raw response directly onto your screen.

Why do programmers rely on it so heavily? Because it is universal. It is installed by default on almost every modern operating system. When you read the documentation for a new API—whether it’s Stripe, GitHub, or OpenAI—they won't show you how to use it in JavaScript or Python first. They will show you a cURL command. It is the universal language of HTTP.

Your First Request

Let’s see it in action. Open your terminal and type this exact command:

curl https://example.com

When you hit Enter, you won't see a formatted webpage. You will see this:

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
...

This is the raw HTML of example.com.

This single command proves a fundamental truth about web development: the web is just text. Your browser hides this text from you by rendering it into a visual layout. cURL rips the mask off and shows you exactly what the server actually sent.

Understanding the Conversation

When you talk to a server, the response it sends back is split into two parts:

  1. The Headers (Metadata): Information about the response (like whether it was successful, the date, and what type of data is attached).

  2. The Body (Data): The actual content you asked for (like the HTML or JSON).

By default, cURL only shows you the Body. But as a developer, you often care more about the Headers, specifically the Status Code, which tells you if your request succeeded (like 200 OK) or failed (like 404 Not Found).

To tell cURL to include the headers in its output, use the -i (include) flag:

curl -i https://example.com

Now, before the HTML, you will see the server's hidden metadata:

HTTP/2 200 
content-type: text/html; charset=UTF-8
date: Sun, 10 May 2026 06:17:00 GMT
...

Talking to APIs

Fetching HTML is cool, but cURL’s real superpower is interacting with APIs. APIs don't return HTML for humans to read; they return structured data (usually JSON) for machines to process.

The GET Request (Reading Data)

If you want to read data from a server, you use a GET request. By default, cURL always makes a GET request, so you don't need any special flags. Let's ask a public API for a mock to-do item:

curl https://jsonplaceholder.typicode.com/todos/1

The server instantly replies with raw JSON:

{
  "userId": 1,
  "id": 1,
  "title": "delectus aut autem",
  "completed": false
}

The POST Request (Sending Data)

What if you don't just want to read data? What if you want to create a new user, or send a form submission? For that, you need to send a POST request.

A POST request requires a bit more information. You have to tell the server:

  1. What HTTP method you are using (POST).

  2. What format your data is in (usually JSON).

  3. The actual data itself.

Here is how you build that in cURL. It looks intimidating at first, but let's break it down:

curl -X POST https://jsonplaceholder.typicode.com/posts \
     -H "Content-Type: application/json" \
     -d '{"title": "My First Post", "body": "cURL is awesome"}'
  • -X POST: The -X flag specifies the exact HTTP method you want to use.

  • -H: The -H flag adds a Header. Here, we are warning the server: "Hey, the data I am about to send you is formatted as JSON."

  • -d: The -d flag stands for data. This is the actual payload you are sending to the server.

If you run this, the API will reply with a 201 Created status and echo your data back to you. You just wrote data to a server without touching a frontend interface.

Image by MDN Web Docs

Common Beginner Mistakes

When you first start using cURL, you will inevitably run into walls. Here are the three most common traps beginners fall into:

  1. Forgetting to quote your URLs: If a URL has an ampersand (&) in it (e.g., https://api.com?search=cat&limit=10), you must wrap the URL in quotes. If you don't, your terminal thinks the & means "run this process in the background," and your command will mysteriously fail or freeze.

    • Wrong: curl https://api.com?search=cat&limit=10

    • Right: curl "https://api.com?search=cat&limit=10"

  2. Sending JSON but forgetting the Content-Type header: If you use the -d flag to send JSON data but forget to include -H "Content-Type: application/json", the server will assume you are sending a standard HTML form submission. It won't know how to read your JSON, and it will throw a 400 Bad Request error.

  3. Confusing single and double quotes: When sending JSON data with -d, wrap the entire payload in single quotes ('...'), and use double quotes ("...") for the keys and values inside the JSON. If you mix them up, the JSON becomes invalid.

Conclusion

Graphical tools like Postman or Insomnia are fantastic, and you will absolutely use them in your career. But relying purely on a GUI hides the mechanics of HTTP.

When you learn cURL, you aren't just learning a terminal command. You are learning how the internet actually communicates. You learn how to manually assemble the headers, the verbs, and the body of a request. Once you can do it in the terminal, writing fetch() requests in JavaScript or handling routes in Node.js becomes infinitely easier—because you finally understand exactly what the code is doing under the hood.