How to use custom cookies with Wget

Automated downloads frequently encounter login prompts, region gates, and per-user throttling that browser sessions bypass effortlessly. Custom cookies allow wget to reuse the authenticated browser state so scripted downloads behave like a signed-in user. Matching the browser’s cookies keeps background jobs aligned with the same access level and preferences available in the interactive session.

Behind the scenes, wget can read a Netscape-style cookie jar such as cookies.txt or send cookies directly as an HTTP Cookie header. A cookie jar stores one cookie per line with fields describing the domain, path, expiry timestamp, Secure flag, and the name–value pair, and wget automatically attaches cookies whose rules match each outgoing request. For quick experiments, passing a single Cookie header with --header provides a lightweight way to inject just the needed values.

Cookie-based automation inherits every privilege of the authenticated browser session and remains subject to expiration times, same-site restrictions, and server-side invalidation. Any file that stores live authentication cookies should stay on trusted storage, with restricted permissions and a short lifetime, because leaked cookies can expose personal data or private repositories. Practical use typically involves a shell environment with wget already installed and a cookie export from a desktop browser in Netscape format.

1. Open a terminal in the directory where downloads should be written.

   $ pwd
   /home/alex/downloads

2. Export cookies for the target site from a browser into a Netscape-format file named cookies.txt in the working directory.

   Browser developer tools and extensions can export the current session’s cookies in Netscape format that wget understands without modification.

3. Inspect the exported cookie file to confirm that domain, path, secure flag, and expiry values match expectations.

   $ cat cookies.txt
   # Netscape HTTP Cookie File
   .example.net  TRUE  / FALSE 1893456000  sessionid xyz123session
   .example.net  TRUE  /account  TRUE  1893456000  auth_token  A1B2C3D4E5
   .analytics.example.net  FALSE / FALSE 1893456000  tracking_id 9f8e7d6c5b

   Each line defines one cookie, and only entries whose domain and path fields match a request are attached to that request by wget.

4. Optionally trim the cookie file to keep only the entries needed for the scripted downloads.

   $ nano cookies.txt

   Breaking the tab-separated layout or column order can cause wget to skip cookies silently, which often appears as mysterious authentication failure.

5. Fetch a protected resource while loading cookies from the file so wget can authenticate like the browser session.

   $ wget --load-cookies cookies.txt https://www.example.net/account/report.csv
   --2025-12-08--  https://www.example.net/account/report.csv
   Resolving www.example.net (www.example.net)... 203.0.113.42
   Connecting to www.example.net (www.example.net)|203.0.113.42|:443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 45231 (44K) [text/csv]
   Saving to: 'report.csv'
   
   report.csv          100% 44.2K  ##### snipped #####

   wget sends every cookie in cookies.txt whose domain and path rules match the URL, reproducing the browser’s authenticated behaviour for that host.

6. Use a single explicit Cookie header instead of a cookie jar when only one or two cookies are required.

   $ wget --header="Cookie: sessionid=xyz123session; auth_token=A1B2C3D4E5" https://www.example.net/account/profile
   --2025-12-08--  https://www.example.net/account/profile
   HTTP request sent, awaiting response... 200 OK
   ##### snipped #####

   The header-based approach is convenient for quick tests but does not track expiry, path, or domain rules the way a cookie jar does.

7. Confirm that the expected file or page content has been retrieved using the supplied cookies.

   $ ls -lh
   total 48K
   -rw------- 1 alex alex 1.7K cookies.txt
   -rw-r--r-- 1 alex alex  44K report.csv
   $ head -n 3 report.csv
   user_id,plan,status
   12345,pro,active
   67890,basic,inactive

   Successful authentication typically shows a 200 OK status in the wget output and a downloaded file whose contents match what appears in the browser.

8. Lock down or delete the cookie file after downloads complete so that sensitive session data is not left behind unnecessarily.

   $ chmod 600 cookies.txt
   $ rm cookies.txt

   Authentication cookies often grant the same access as a logged-in browser until expiry or server-side revocation, so leaked cookie files can be used to impersonate the original user.