Quick Answer
Use wget when you need a repeatable download test, a resumable file transfer, or a simple way to check whether a URL works outside the browser. wget is honest: it shows you exactly what the server returns, without browser caching, extensions, or download managers masking the real behaviour.
Essential Examples
# Basic download
wget https://example.com/file.zip
# Resume an interrupted download
wget -c https://example.com/file.zip
# Check if a URL works without downloading
wget --spider https://example.com/page
# Show HTTP headers for debugging
wget --server-response https://example.com/
# Download quietly, output to a specific filename
wget -q -O myfile.zip https://example.com/file.zip
# Retry 3 times with 10-second timeout per attempt
wget --tries=3 --timeout=10 https://example.com/file.zip
# Limit download speed (useful for testing throttling)
wget --limit-rate=1m https://example.com/largefile.iso
# Download in background, log to a file
wget -b -o wget.log https://example.com/largefile.iso
Common Flag Reference
| Flag | What It Does | Use Case |
|---|---|---|
-c | Continue/resume partial download | Recovering interrupted large file downloads |
--spider | Check URL without saving | Confirm a URL is reachable and returns 200 |
--server-response | Print full HTTP response headers | Debug redirects, caching headers, content type |
-q | Quiet mode — minimal output | Scripts and cron jobs |
-O filename | Save to a specific filename | Override the server-provided filename |
--tries=N | Retry N times on failure | Unreliable servers or flaky connections |
--timeout=N | Set connect/read timeout in seconds | Avoid hanging on unresponsive servers |
--limit-rate=N | Cap download speed (k, m suffix) | Test throttling; avoid saturating a connection |
-b | Run in background | Long downloads you do not want to babysit |
-r | Recursive download | Mirror a website or directory listing |
--no-check-certificate | Skip SSL verification | Testing self-signed certs in controlled environments |
Testing Download Speed with wget
wget is a reliable way to isolate download speed from browser behaviour. The transfer rate printed at the end of a download reflects the actual throughput between your connection and that server — no caching, no pre-fetching, no extensions. To test against a known large file from a fast server:
# Download a test file from a speed test server
wget -O /dev/null http://speedtest.tele2.net/100MB.zip
# Save output to check the reported transfer rate
wget --server-response -O /dev/null https://proof.ovh.net/files/100Mb.dat 2>&1 | tail -5
The -O /dev/null discards the file so you are measuring transfer speed without disk write time interfering. Compare the wget result to a browser-based speed test to see if the browser or a CDN is responsible for differences.
Interpreting wget Errors
| Error | Likely Cause | Next Step |
|---|---|---|
| Connection refused | Server not listening on that port | Verify port and protocol; try curl -v |
| Connection timed out | Firewall blocking, routing issue, or server down | Try ping and traceroute to the host |
| 404 Not Found | URL path does not exist | Check the URL; use --server-response to see redirect chain |
| SSL handshake failure | Certificate error or TLS version mismatch | Check system date/time; try curl for more detail |
| Download stalls mid-transfer | Packet loss, server throttling, or route issue | Retry with --tries; run mtr to check the route |
| Speed much lower than ISP plan | Single-connection limit to that server, CDN throttling | Try a different test server; use a browser speed test |
wget vs curl
wget and curl solve overlapping but different problems. Use wget when the job is downloading files — it handles retries, resumes, and recursive mirroring well with simple flags. Use curl when the job involves HTTP requests — it supports all methods (POST, PUT, DELETE), custom headers, form data, cookies, and API workflows with more precision. Both are worth knowing.
Frequently Asked Questions
Is wget the same as curl?
No. wget is download-focused with built-in retry, resume, and recursive crawl. curl is request-focused with more control over HTTP methods, headers, and authentication. For pure file downloads, wget is simpler. For API testing and custom HTTP interactions, curl is more capable.
Can wget resume downloads?
Yes, use wget -c URL. The server must support HTTP range requests (most modern servers do). wget checks the local file size and sends a range request starting from where it left off. If the server does not support ranges, wget will restart from the beginning.
Why is wget faster than my browser?
Browsers apply extension-based scanning, may throttle downloads to check files, use different CDN routing, and sometimes limit single-connection speeds. wget bypasses all of that. If wget is consistently faster than your browser for the same file, a browser extension or setting is the likely cause.
Does wget work on macOS?
It is not installed by default on macOS, but it is available via Homebrew: brew install wget. macOS includes curl by default, which handles most of the same tasks.