Use curl -L -o filename URL when you need precise control over a download, and use wget URL when you want a quick save with minimal typing. Both tools can download files from the command line, but they feel different in real work. curl is more like a flexible transfer engine. wget is more like a file grabber built for saving things fast.
TLDR: For saving a single file, wget https://example.com/file.zip is usually simpler, while curl -L -o file.zip https://example.com/file.zip gives you better control over names, redirects, headers, and authentication. In a build script that downloads a 42 MB release artifact 30 times a day, switching from browser downloads to curl can cut manual steps to zero and make failures easier to log. Use wget for recursive downloads and mirrored folders; use curl for APIs, tokens, forms, and repeatable automation.
Saving a file with curl
The most common curl mistake is running a command and watching binary junk spray across the terminal. Annoying, loud, and useless. By default, curl writes the response to standard output, not to a file. To save it, you need to tell curl where the bytes should go.
curl -o report.pdf https://example.com/report.pdf
The -o option means output. You choose the local filename. If you want curl to keep the remote filename, use uppercase -O instead:
curl -O https://example.com/files/manual.pdf
Many modern download links redirect through CDNs, login gateways, or versioned release URLs. Add -L so curl follows redirects:
curl -L -o app.tar.gz https://example.com/latest
This is the command most people should memorize. It is clear, scriptable, and safe from random terminal output.
curl vs wget: the practical difference
curl and wget overlap, but they were built with different habits in mind. wget assumes you probably want to save a file. curl assumes you may want to send, inspect, pipe, test, authenticate, or save data.
- Use curl when: you need headers, tokens, POST requests, custom methods, cookies, proxies, or API calls.
- Use wget when: you want to download files, resume interrupted transfers, or mirror web directories.
- Use curl in scripts when: exact output names and error handling matter.
- Use wget for convenience when: the URL already points to the file you want.
For example, this is simple with wget:
wget https://example.com/archive.zip
It saves archive.zip automatically. The equivalent in curl is:
curl -O https://example.com/archive.zip
The difference looks tiny. It matters once links get messy. A download URL like https://example.com/download?id=9182 gives wget very little to work with for a filename. With curl, you can name the file yourself:
curl -L -o customer-export.csv "https://example.com/download?id=9182"
When wget feels better
wget is excellent when you are grabbing public files from a server. It has friendly defaults. It saves files without extra flags. It can continue a broken download with -c:
wget -c https://example.com/large-video.mp4
That matters on flaky connections. If a 3 GB file stops at 82%, nobody wants to start over. Honestly, it feels like punishment when a tool makes you repeat a huge transfer because Wi Fi hiccupped for two seconds.
wget also shines for recursive downloads:
wget -r -np -nH --cut-dirs=1 https://example.com/docs/
This can fetch a folder structure from a site. Be careful. Recursive downloads can grab far more than you expect. A small documentation folder can turn into thousands of files if links point outward.
When curl wins
curl is the better choice when a file download is tied to an API or an authenticated workflow. Need a bearer token? Easy:
curl -L -H "Authorization: Bearer TOKEN" -o backup.zip https://api.example.com/backup
Need to send form data before receiving a file?
curl -L -X POST -d "format=csv" -o users.csv https://example.com/export
Need to fail a script if the server returns an error? Add --fail:
curl --fail -L -o release.zip https://example.com/release.zip
This is where curl feels built for automation. You can combine it with shell checks, logs, cron jobs, CI pipelines, and deployment scripts. It drives me crazy that some examples skip --fail; without it, a script may save an HTML error page as if it were a valid ZIP file.
Useful curl save file options
-o name: Save output as a specific filename.-O: Save using the remote filename.-L: Follow redirects.--fail: Return an error on bad HTTP status codes.-C -: Resume a partially downloaded file.--retry 3: Retry failed transfers up to three times.-sS: Run quietly but still show errors.
A strong script-friendly download command looks like this:
curl --fail --retry 3 -L -C - -o dataset.csv https://example.com/dataset.csv
That command follows redirects, retries failures, resumes partial downloads, and saves to a known filename. It is not pretty, but it is sturdy.
Command-line download alternatives
curl and wget are the classics, but they are not the only options. Some alternatives are faster, friendlier, or better for a specific job.
- aria2: A powerful downloader with parallel connections, BitTorrent support, metalink support, and resume features. Good for large files.
- HTTPie: A readable HTTP client. Great for APIs, less focused on raw file downloading.
- PowerShell Invoke-WebRequest: Built into Windows environments and useful for admin scripts.
- scp: Copies files over SSH. Best for server-to-server file movement.
- rsync: Syncs folders efficiently. Excellent for backups and repeated transfers.
- Python: Handy when download logic needs parsing, checksums, or custom error handling.
For speed, aria2 can be impressive:
aria2c -x 8 -s 8 https://example.com/big.iso
Here, -x 8 allows up to eight connections per server, while -s 8 splits the download into eight parts. On a good server, that can cut download time sharply. On a weak server, it may not help at all.
Security checks after downloading
Saving the file is only half the job. If you are downloading installers, archives, or scripts, verify them. Many projects publish SHA256 checksums. After downloading, compare the hash:
sha256sum app.tar.gz
On macOS, use:
shasum -a 256 app.tar.gz
If the checksum does not match, delete the file. Do not run it. A corrupted file can break a deployment. A tampered file can do much worse.
Which one should you choose?
Pick wget when you want the shortest path from URL to saved file. Pick curl when the request needs control, headers, authentication, redirects, or clean scripting. Pick aria2 when large downloads need speed. Pick rsync when files must stay synced over time.
For daily use, learn these two commands first:
wget https://example.com/file.zip
curl -L -o file.zip https://example.com/file.zip
Those cover most downloads. After that, add retries, resume support, authentication, and checksum checks as needed. The command line is not just faster than clicking through a browser. It is repeatable, visible, and easier to fix when something breaks.