Learn Curl - History, Background & Why the World Needs Curl

#Introduction

After setting up the environment in episode 0 — making sure curl 8.21.x is installed and verified — in this episode we'll take a short break from hands-on work and understand why curl exists. A tool's history and background may feel unimportant, but that's exactly where the reason for its current design lies.

Why must you understand curl's history? Because curl isn't a project born from a corporate boardroom, but from a very simple real-world need in 1996. Understanding its origins explains many design decisions — why curl supports dozens of protocols, why it ships as both a CLI and a library, and why it's still the first choice of millions of engineers today. You'll realize that curl is not just "a download command", but a de-facto standard that's more than 25 years old.

#The Beginning: httpget (1996)

The curl story begins in Sweden, in the hands of a developer named Daniel Stenberg. In 1996, Daniel was working on Irssi — an IRC client — and wanted to offer IRC users a way to automatically check currency exchange rates. To do that, he needed to fetch data from an HTTP-based server.

The problem: back then, no practical tool existed for that simple task. The available tools felt heavy and didn't fit. So, as is the habit of a good engineer, Daniel wrote his own small tool and named it httpget — exactly as its name suggests: a tool to get (fetch) over HTTP.

httpget grew along with the needs. Irssi users wanted support for other protocols — starting with FTP, then gopher. The httpget code began to "branch out" and every fork carried its own copy — a maintenance nightmare. In 1998, Daniel decided to unify all those branches into a single new project named curl — popularly interpreted as Client for URL.

#The Birth of libcurl: An Engine Anyone Can Borrow

One decision that changed everything happened in the early 2000s. As curl grew more popular, people started asking: "can I use curl's transfer engine inside my own program?"

Daniel answered by separating the core transfer engine into a standalone library named libcurl. From that point on, curl officially consisted of two faces:

1. curl — the CLI program you type in the terminal.
2. libcurl — the library that can be called from any programming language.

This was a highly strategic decision. libcurl allowed other applications — browsers, mobile apps, servers, backup tools — to borrow curl's data transfer capabilities without rewriting from scratch. That's what made curl more than just a popular tool: it became infrastructure foundation — millions of applications around the world run libcurl without their users ever knowing it.

curl -L https://example.com

curl_easy_init();
curl_easy_setopt(curl, CURLOPT_URL, "https://example.com");
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
curl_easy_perform(curl);
curl_easy_cleanup(curl);

Notice the example above: the same thing — fetch a page and follow redirects — takes a single line in the CLI, while libcurl needs several API calls. The CLI hides all the details behind simple options; libcurl gives developers full control. We'll dig deeper into both faces in episode 2.

#A De-Facto Standard for Over 25 Years

Since being unified in 1998, curl has shipped releases consistently up to today. Up to version 8.21.0, the project has made around 275 releases — almost one release every six weeks for more than two decades. That's proof of a project that's alive and managed with discipline.

Why has curl been able to survive and dominate? Several reasons:

• Portability. curl compiles and runs on almost every operating system: Linux, macOS, Windows, BSD, Android, even embedded devices. It's nearly impossible to find a modern system without it.
• Stability. The CLI option interface and the libcurl API are strictly kept backward compatible. Scripts you write today will still work with next year's curl.
• Openness. An open source project with a permissive license, so any company can use it freely without licensing worries.

The analogy: like TCP/IP or JSON — technologies whose presence is rarely noticed, but which have become the unwritten standards holding up the entire internet. Curl is one of the few tools you could say is "everywhere".

#The Problem Curl Solves

The core problem curl solves is simple to say, but hard to do well: one tool to transfer data using URL syntax across various protocols.

Before curl, every protocol needed a different tool: ftp for FTP, telnet for Telnet, and so on. Curl unifies them all with one shared syntax — the URL. Here's the list of protocols supported by curl 8.21:

With one shared syntax, you can send files to an FTP server with curl ftp://..., read email with curl imap://..., or talk to an MQTT broker — without switching tools.

#Main Use-Case Scenarios

#curl CLI vs libcurl: When to Use Which?

You'll spend most of this series with the curl CLI, so let's set the boundary from the start. Check your build first — the list of protocols and features can be read via curl --version:

• Use the curl CLI when working in a terminal: trying out APIs, debugging, writing bash scripts, or automating something on a server.
• Use libcurl when building an application that needs programmatic data transfer — for example adding upload capability to a desktop app, or a download feature on an internal server.

One reassuring thing: everything you learn in the CLI also applies to libcurl. Every CLI option is essentially a wrapper around one libcurl setting — -L is CURLOPT_FOLLOWLOCATION, -d is CURLOPT_POSTFIELDS, and so on. Learning the CLI is the shortest path to understanding libcurl.

#Brief Timeline

#Closing

In this episode 1, you've traced curl's journey from a simple need on IRC in 1996 — httpget — to a de-facto standard for URL-based data transfer that's more than 25 years old with around 275 releases. You also understand curl's two faces (CLI and libcurl) and the real problem it solves: one tool for dozens of protocols.

Key takeaways:

• Curl was born from a real need (1996) and unified as a project in 1998.
• libcurl is the transfer engine other applications can borrow; the curl CLI is its most popular face.
• Support for dozens of protocols through a single URL syntax is its main differentiator.
• Behind its simplicity, curl is internet infrastructure — not just a download tool.

In the next episode 2, we'll dissect curl's core concepts and main architecture — what actually happens behind a single line of command: from URL parsing, DNS resolution, TCP/TLS connection, to sending and receiving data. We'll also get to know the core options and the language of exit codes that will accompany you throughout the series. See you in episode 2!