Saving cookies from a cURL response keeps stateful HTTP workflows usable across separate command invocations. Login handoffs, form submissions, and endpoints that personalize output often depend on a session cookie that must survive the first request before the next call can continue in the same context.

When a server replies with Set-Cookie headers, cURL can store those values in a Netscape-format cookie jar with --cookie-jar. That jar is write-only for the current transfer, while --cookie reads previously saved cookies back into later requests; both options can point to the same file when a workflow both reuses and refreshes session state.

Cookie jars are plain-text files that can contain live session identifiers, so they should stay in a private path and be removed when the workflow ends. Many cookie-setting endpoints also redirect after authentication or state changes, which makes --location important in practical flows, and reusing an older jar can be limited with --junk-session-cookies when a fresh session is required.

Steps to save cookies from a cURL request:

  1. Create a dedicated workspace for the cookie jar and related request artifacts.
    $ mkdir -p ~/curl-cookie-save
    $ cd ~/curl-cookie-save

    Keeping the jar in one temporary directory makes cleanup and permission checks easier after testing.

  2. Send a request that returns a cookie and write the response cookies to a jar file.
    $ curl -sS -L --cookie-jar cookies.txt 'https://httpbin.org/cookies/set?portal_session=sess_a83f0b9e4c2d7186f54a1b03c9d27ef1'
    {
      "cookies": {
        "portal_session": "sess_a83f0b9e4c2d7186f54a1b03c9d27ef1"
      }
    }

    --cookie-jar writes cookies after the transfer completes, and -L follows the redirect that httpbin uses after setting the cookie.

  3. Inspect the saved jar header and cookie row to confirm that cURL persisted the response state.
    $ sed -n '1,5p' cookies.txt
    # Netscape HTTP Cookie File
    # https://curl.se/docs/http-cookies.html
    # This file was generated by libcurl! Edit at your own risk.
    
    httpbin.org	FALSE	/	FALSE	0	portal_session	sess_a83f0b9e4c2d7186f54a1b03c9d27ef1

    Each cookie occupies one tab-separated line with domain, subdomain rule, path, secure flag, expiry, name, and value.

  4. Restrict the jar permissions to the current account before reusing it in later requests.
    $ chmod 600 cookies.txt

    Cookie jars are plain text, so broad read access can expose active sessions to other users or processes on the same host.

  5. Reuse the saved jar on a later request to confirm that the cookie is being sent back to the server.
    $ curl -sS --cookie cookies.txt https://httpbin.org/cookies
    {
      "cookies": {
        "portal_session": "sess_a83f0b9e4c2d7186f54a1b03c9d27ef1"
      }
    }

    --cookie reads the jar and sends only cookies that match the request host, path, and security rules.

  6. Refresh the same jar by reading and writing it in one command when the server issues an updated cookie value.
    $ curl -sS -L --cookie cookies.txt --cookie-jar cookies.txt 'https://httpbin.org/cookies/set?portal_session=sess_b94c1da50738e62f4a9d11bc8e3f2607'
    {
      "cookies": {
        "portal_session": "sess_b94c1da50738e62f4a9d11bc8e3f2607"
      }
    }

    Using one file for both options keeps follow-up requests aligned with servers that rotate session values after login or account changes.

  7. Verify that the updated jar is now used on the next request.
    $ curl -sS --cookie cookies.txt https://httpbin.org/cookies
    {
      "cookies": {
        "portal_session": "sess_b94c1da50738e62f4a9d11bc8e3f2607"
      }
    }

    The changed value confirms that the earlier response was written back into the jar and reused on the next call.

  8. Remove the jar when session reuse is no longer needed.
    $ rm -f cookies.txt

    Deleting the jar prevents accidental reuse in a later run; if the file must stay in place but session cookies should be ignored, load it with --junk-session-cookies.