Use curl when you need precise HTTP control, scripting, APIs, headers, redirects, or authentication; use wget when you want simple file downloads, recursive fetching, or easy resume behavior. Both tools are reliable, but they solve slightly different problems. For most server scripts and CI jobs, curl is the safer default because it is explicit and widely installed.
TLDR: If you need to download one file with curl, run curl -L -o file.zip https://example.com/file.zip. If your team downloads 500 MB release builds several times a day, wget -c may save time because it resumes broken downloads with less fuss. In a small automation setup, replacing browser downloads with curl or wget can cut manual transfer work by 80% or more. Use alternatives such as aria2, HTTPie, or PowerShell when you need parallel downloads, friendlier syntax, or native Windows behavior.
Contents
Downloading a file with curl
The standard curl command for file downloads is short:
curl -L -o archive.zip https://example.com/archive.zipThe -L option follows redirects. This matters because many download links point first to a tracking URL, CDN, or signed URL. The -o option writes the response to a specific filename.
If you want to keep the remote filename, use -O:
curl -L -O https://example.com/files/report.pdfFor downloads that may fail on poor connections, add resume support:
curl -L -C - -o archive.zip https://example.com/archive.zip-C - tells curl to continue from where the partial file stopped. It works only if the server supports byte ranges. Most serious CDNs do, but not all internal file servers are configured well. Honestly, it feels like half the pain in downloads comes from servers pretending to support standards, then failing at the worst time.
Common curl download examples
- Download with a custom filename:
curl -L -o backup.tar.gz https://example.com/backup - Download and show errors only:
curl -fsSL -o app.deb https://example.com/app.deb - Download with a bearer token:
curl -L -H "Authorization: Bearer TOKEN" -o data.json https://api.example.com/export - Download with basic authentication:
curl -u user:password -L -o file.zip https://example.com/private/file.zip - Save response headers too:
curl -D headers.txt -L -o file.bin https://example.com/file.bin
For scripts, curl -f is useful. It makes curl fail on HTTP errors such as 404 or 500. Without it, your script may create a file that contains an error page instead of the actual download. That small mistake can waste 20 minutes during a deployment.
curl vs wget: which should you use?
curl is a transfer tool. It supports many protocols, rich HTTP options, request methods, headers, cookies, proxies, TLS settings, and authentication flows. It is excellent for APIs and automation where exact behavior matters.
wget is more focused on retrieval. It is built around downloading files and websites. It has simple defaults, recursive download support, timestamp checks, and practical resume behavior. If you want to mirror a folder or fetch many linked files, wget often feels more natural.
| Use case | Better choice | Reason |
|---|---|---|
| Download one file in a script | curl |
Explicit options, strong error handling |
| Resume a large file | wget |
wget -c is simple and familiar |
| Call an authenticated API | curl |
Headers and methods are easier to control |
| Mirror a website | wget |
Recursive download is built in |
| Run on minimal containers | curl |
Often already present in base images |
The catch is that both tools have flags that look similar but behave differently. curl -O uses the remote filename. wget does that by default. curl does not follow redirects unless you add -L. wget usually follows them with less ceremony. These differences are small until they break a release script at 2 a.m.
When wget is the easier option
For a plain download, wget is hard to beat:
wget https://example.com/file.zipTo resume an interrupted transfer:
wget -c https://example.com/file.zipTo download a list of URLs:
wget -i urls.txtTo mirror a site for offline review:
wget --mirror --convert-links --page-requisites https://example.comThat last command is exactly where wget earns its place. Doing the same with curl is possible only with extra scripting. Expect to waste time on edge cases such as relative links, assets, and redirect chains.
HTTP download tool alternatives
aria2 is the best choice when speed matters. It can download from multiple sources and open several connections per file.
aria2c -x 8 -s 8 https://example.com/large.isoHere, -x 8 allows up to eight connections per server, while -s 8 splits the download into eight parts. On a fast CDN, this can reduce a 4 GB ISO download from 6 minutes to about 3 or 4 minutes. Results vary, but the gain is real on high-latency links.
HTTPie is friendlier for humans. It is often used for APIs, but it can save files too:
http --download https://example.com/file.zipIts output is cleaner than curl for inspecting requests and responses. It is less common on servers, so it is not always the best option for portable scripts.
PowerShell is the practical Windows option:
Invoke-WebRequest -Uri "https://example.com/file.zip" -OutFile "file.zip"On modern Windows systems, this avoids installing extra tools. It also works well in administrative scripts. For cross-platform teams, though, syntax differences can become annoying.
Python is useful when downloads need extra logic:
python -c "import urllib.request; urllib.request.urlretrieve('https://example.com/file.zip','file.zip')"This is not as clean as curl, but it helps when you already have a Python deployment script and need checksums, retries, or custom naming.
Security checks after downloading
Downloading is only half the job. You also need to verify what you received. Serious vendors publish SHA256 checksums or signatures. Use them.
sha256sum file.zipCompare the output with the vendor’s published checksum. If the values differ, delete the file. Do not run it. This protects against broken transfers, wrong versions, and tampered files.
For scripts, add strict error handling. A safer Linux shell pattern looks like this:
set -e
curl -fsSL -o app.tar.gz https://example.com/app.tar.gz
echo "expected_hash app.tar.gz" | sha256sum -c --f fails on HTTP errors. -sS keeps output quiet but still shows errors. -L follows redirects. Together, they make curl far more dependable in automation.
Best practical choice
Choose curl for APIs, scripted downloads, authentication, headers, CI pipelines, and strict error handling. Choose wget for simple file retrieval, resumed downloads, batch URL lists, and website mirroring. Choose aria2 when large files need to arrive faster.
If you remember only one command, make it this:
curl -fsSL -o file.zip https://example.com/file.zipIt is compact, script-friendly, and fails cleanly when the server returns an error. Add -C - for resume support, add headers when authentication is required, and verify the checksum before running anything you downloaded.
