How to use custom cookies with wget

Some authenticated downloads are easiest to reproduce by replaying the exact cookies already issued by the target site. wget can send those values either from a Netscape-format cookie jar or from a raw Cookie: request header, which is useful for short validation runs and browser-to-CLI handoffs.

The safer method is --load-cookies because wget honors the stored domain, path, expiry, and secure flags for each cookie. The lighter method is --header="Cookie: ...", which injects the cookie string exactly as written and bypasses the normal jar matching logic. GNU wget documentation still treats the raw header approach as the fallback when a usable Netscape cookie file cannot be produced.

Custom cookies are still credentials. Keep the jar or header value out of shared directories, prefer short-lived sessions, and confirm the protected response body before using the result in a larger automation chain.

1. Create and enter a dedicated directory for the cookie material and downloaded output.

   $ mkdir -p "$HOME/wget-custom-cookies"
   $ cd "$HOME/wget-custom-cookies"

   Isolation makes it easier to review, rotate, and remove cookie data when the task is complete.

2. Write or export the custom cookies in Netscape format when the site relies on normal domain and path matching.

   $ cat > custom-cookies.txt <<'EOF'
   # HTTP Cookie File
   # Generated for wget custom cookie test.
   
   httpbin.org	FALSE	/	FALSE	0	auth_token	A1B2C3D4E5
   httpbin.org	FALSE	/	FALSE	0	sessionid	xyz123session
   EOF

   Browser cookie-export tools usually produce this same format, so manual editing is only needed when a small test jar is enough.

3. Restrict the cookie jar before reuse and confirm the expected rows are present.

   $ chmod 600 custom-cookies.txt
   $ sed -n '1,8p' custom-cookies.txt
   # HTTP Cookie File
   # Generated for wget custom cookie test.
   
   httpbin.org	FALSE	/	FALSE	0	auth_token	A1B2C3D4E5
   httpbin.org	FALSE	/	FALSE	0	sessionid	xyz123session

   Restrictive permissions reduce the chance of another local process replaying the same authenticated session.

4. Load the jar with --load-cookies and verify that both cookie values reach the remote service.

   $ wget --load-cookies custom-cookies.txt -qO- https://httpbin.org/cookies
   {
     "cookies": {
       "auth_token": "A1B2C3D4E5",
       "sessionid": "xyz123session"
     }
   }

   Jar-based delivery is the better default for repeatable automation because wget applies the stored scope rules instead of sending every value to every host.

5. Fall back to a raw Cookie: header only when a jar is unavailable or when one short request is enough.

   $ COOKIE_HEADER='sessionid=xyz123session; auth_token=A1B2C3D4E5'
   $ wget --no-cookies --header="Cookie: $COOKIE_HEADER" -qO- https://httpbin.org/cookies
   {
     "cookies": {
       "auth_token": "A1B2C3D4E5",
       "sessionid": "xyz123session"
     }
   }

   The raw header bypasses jar expiry and path matching, so keep it for narrow test cases rather than long-running scheduled jobs.

6. Clear temporary shell variables and confirm the protected response body looks authenticated before proceeding.

   $ unset COOKIE_HEADER
   $ wget --load-cookies custom-cookies.txt -qO- https://httpbin.org/cookies | grep --fixed-strings '"sessionid": "xyz123session"'
       "sessionid": "xyz123session"

   Check for account-specific data, expected JSON keys, or the normal page title so a login redirect is not mistaken for success.

7. Remove the cookie jar after the workflow completes.

   $ rm -f custom-cookies.txt

   Deleting the jar after use keeps reusable session material from lingering on disk longer than necessary.