Store and reuse cookies

HTTP is stateless. Servers use cookies to recognize you across requests. You log in once, and a session cookie proves who you are on every request after that.

Your browser handles this invisibly. curl does not. Each curl command is a stranger to the server, unless you give it a cookie jar, a file where cookies are saved and read back.

This default explains a lot of “it works in the browser but not in curl” reports. Nine times out of ten, a cookie is missing. To script anything session-based, you need the jar.

Write, then read

Save cookies with one command and send them back with another:

curl --cookie-jar cookies.txt 'https://httpbin.org/cookies/set?theme=dark'
curl --cookie cookies.txt https://httpbin.org/cookies

The first command hits an endpoint that sets a cookie. --cookie-jar cookies.txt saves everything the server set. The second command sends the jar back with --cookie cookies.txt, and the server shows what it received:

{
  "cookies": {
    "theme": "dark"
  }
}

Two separate processes, one continuous session. That’s the whole mechanism.

For a realistic login flow, use both options on every command. Read the existing cookies, and save any updates the server sends:

curl --cookie cookies.txt --cookie-jar cookies.txt https://httpbin.org/cookies

I always pass both. It costs nothing, and it means a server that refreshes the session cookie mid-flow doesn’t silently log me out.

Look inside the jar

The jar is a plain text file in the Netscape cookie format, one cookie per line:

httpbin.org	FALSE	/	FALSE	0	theme	dark

Each field maps to a rule. The domain and path decide which requests the cookie travels with. The secure flag restricts it to HTTPS. The expiry, 0 here, means a session cookie.

When a cookie mysteriously isn’t sent, the answer is almost always in one of these fields. The domain doesn’t match. The path is too narrow. The expiry has already passed. Open the file and read the line before you blame the server.

The jar is a credential

A saved session cookie is login-equivalent. Anyone who reads the file can be you until the session expires.

Keep jars out of Git. Restrict permissions with chmod 600 cookies.txt. And remove the lab file when you’re done:

rm cookies.txt

Treat the jar with exactly the care you’d give the password that created it.

Try this on a site where you have an account: log in with curl using --data and both cookie options, then request a page that needs the session. Then open the jar and find the session cookie’s expiry.