Ik heb belachelijk veel late avonden besteed aan het debuggen van scripts die zogenaamd alleen even "een bestand moesten ophalen en doorgaan". In negen van de tien gevallen was de boosdoener cURL — die deed precies wat ik had gevraagd, niet wat ik eigenlijk bedoelde. Er zit namelijk een flink verschil tussen "curl -O werkt" en "curl -O werkt ook betrouwbaar in productie."
Daarvoor is deze gids bedoeld. cURL wordt standaard meegeleverd op macOS, de meeste Linux-distributies en Windows 10 en nieuwer, dus de kans is groot dat je het al op je machine hebt staan. Maar tussen stille redirect-fouten, mysterieuze 403’s en de sprong van "één bestand downloaden" naar "500 bestanden downloaden zonder je terminal te laten vastlopen" kun je makkelijk vastlopen. Ik neem je mee langs de flags die echt tellen, de stappen die ik zelf gebruik, de fouten waar mensen het vaakst op struikelen, en het punt waarop cURL je echt niet verder kan helpen — plus wat je dan beter kunt gebruiken.
Wat is cURL (en waarom zou je het gebruiken)?
cURL is een gratis, open-source command-line tool om data van of naar een server over te zetten via een URL. Het ondersteunt HTTP, HTTPS, FTP, SFTP en nog een hele reeks andere protocollen. Daarom kom je het overal tegen: in bash-scripts, Dockerfiles en CI-pipelines. Onder de motorkap gebruikt het curl-commando dat je in je terminal typt libcurl, de C-transferbibliotheek die veel applicaties en language bindings inbouwen. De cURL-extensie van PHP is een voorbeeld; de populaire Requests-bibliotheek in Python is juist een aparte HTTP-client die op urllib3 draait, niet op libcurl.
De huidige stabiele release op het moment van schrijven is curl 8.21.0, uitgebracht in juni 2026 — maar ga er niet zomaar van uit dat je besturingssysteem exact die build meelevert. Door distributies verpakte versies lopen vaak maanden achter op de upstream-versie, soms nog langer. Het is dus slim om eerst curl --version te draaien voordat je ervan uitgaat dat een flag zoals --parallel beschikbaar is.
Waarom bestanden downloaden met cURL? De belangrijkste use cases
Ik krijg vaak de vraag waarom je überhaupt een command-line tool zou gebruiken als browsers bestanden prima kunnen downloaden. Het eerlijke antwoord: browsers zijn geweldig, totdat je iets wilt automatiseren.
| Use Case | Waarom cURL uitblinkt |
|---|---|
| Binaries downloaden in CI/CD-pipelines | Scriptbaar, geen GUI nodig |
| API-responses of data-exports ophalen | Ondersteunt custom headers, authenticatie en output piping |
| Grote downloads hervatten via SSH | Ingebouwde support voor hervatten (-C -) |
| Terugkerende downloads automatiseren (cronjobs) | Lichtgewicht en goed te combineren met shell-scripts |
| Bestanden ophalen achter authenticatie | Flexibele auth-flags (basic, token, cookies, .netrc) |
Een browserdownload is een losse handmatige klik. cURL maakt van dezelfde handeling iets dat je kunt inplannen, koppelen aan een pipeline, automatisch opnieuw kunt proberen bij fouten en op honderd servers tegelijk identiek kunt uitvoeren. Dat is precies de kracht: niet mooier, maar wel herhaalbaar.
De belangrijkste cURL-flags voor het downloaden van bestanden
Ik kom steeds terug op ongeveer een dozijn flags die goed zijn voor 90% van wat ik doe. Dit is het overzicht dat ik jaren geleden had willen krijgen, gegroepeerd op wat ze echt doen.
Flags voor output en bestand opslaan
-O(--remote-name) slaat het bestand op met het laatste deel van de URL als bestandsnaam. Handig, maar het kan zonder waarschuwing een bestaand bestand met dezelfde naam overschrijven.-o <bestandsnaam>(--output) laat je zelf de exacte bestandsnaam kiezen:curl -o report.pdf https://example.com/downloads/file.pdf.-J(--remote-header-name) gebruikt de bestandsnaam uit deContent-Disposition-header van de server in plaats van de URL. Handig bij API-downloads, maar behandel server-geleverde bestandsnamen als onbetrouwbare input — download liever naar een aparte map dan naar je home-directory, zoals de eigen beveiligingsrichtlijnen van curl adviseren.
Gedragsflags die elke download nodig heeft
-L(--location) zorgt ervoor dat curl HTTP-redirects volgt. Zonder deze flag wordt een 3xx-response vaak opgeslagen als een klein HTML-redirectpaginaatje in plaats van je echte bestand — dit is veruit de meest voorkomende "waarom is mijn download kapot"-fout die ik zie.-C -(--continue-at -) hervat een onderbroken download waar hij was gebleven.-s/-Sdraaien stil, maar tonen wel fouten — handig voor scripts waarin je geen voortgangsbalk in je logs wilt.--limit-rate 1Mbeperkt de bandbreedte (handig op gedeelde verbindingen of als je een datalimiet niet wilt opvreten).--connect-timeout 10en--max-time 300voorkomen dat een vastgelopen verbinding je script eindeloos laat hangen.--retry 3en--retry-delay 5proberen automatische herhalingen bij tijdelijke fouten — volgens de curl-manpagina moet je dit alleen combineren met--retry-all-errorsals het echt veilig is om exact dezelfde aanvraag opnieuw te doen.
Flags voor voortgang en debugging
-#geeft je een simpele voortgangsbalk in plaats van de standaard statistiektabel.-vtoont uitgebreide output, inclusief de volledige request- en responseheaders — mijn vaste keuze als iets niet goed werkt.-I(--head) haalt alleen de responseheaders op, ideaal als snelle check vóór je een grote download start.-wlaat je aangepaste output printen na de overdracht, bijvoorbeeldcurl -o /dev/null -s -w "%{http_code}\n" <url>om alleen de statuscode te controleren.
Voordat je begint
- Moeilijkheid: Beginner tot Intermediate (de batch- en auth-secties worden wat gevorderder)
- Benodigde tijd: Ongeveer 15-20 minuten om de kerncommando’s door te nemen
- Wat je nodig hebt: Een terminal (macOS Terminal, Linux-shell of Windows PowerShell/WSL), curl geïnstalleerd (check met
curl --version) en een test-URL — ik gebruik als voorbeeld een openbaar GitHub-releasebestand, omdat dat stabiel en gratis toegankelijk is
Bestanden downloaden met cURL: stap voor stap
Stap 1: Download een enkel bestand
De absolute basis: curl -O <url> slaat het bestand op onder de oorspronkelijke naam, terwijl curl -o mijnbestand.zip <url> je de naam laat aanpassen tijdens het downloaden.
curl -LO https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
Ik voeg tegenwoordig standaard -L toe, altijd, zonder uitzondering — ik ben te vaak de mist in gegaan doordat een redirect mijn "download" stilletjes veranderde in een HTML-bestand van 400 bytes. Je zou een voortgangsmeter moeten zien in je terminal, waarna het bestand in je huidige map staat.
Als het commando slaagt, loopt de voortgangsmeter naar 100% en verschijnt curl-8.21.0.tar.gz in de huidige map. Controleer het bestand voordat je het gebruikt:
ls -lh curl-8.21.0.tar.gz
Stap 2: Download het bestand en geef het een andere naam
Gebruik -o als je een specifieke lokale bestandsnaam wilt in plaats van wat er toevallig aan het eind van de URL staat:
curl -L -o curl-latest.tar.gz -S https://github.com/curl/curl/releases/download/curl-8_21_0/curl-8.21.0.tar.gz
De -S zet foutmeldingen weer aan als je elders in een script ook -s hebt gebruikt. Deze combinatie — -L -o <naam> -S — is eigenlijk mijn standaardcommando voor één bestand.
Stap 3: Hervat een onderbroken download
Als een grote download halverwege wegvalt (slechte wifi, VPN-storing, noem maar op), begin dan niet opnieuw. Gebruik:
curl -C - -LO https://example.com/large-file.iso
Let op: dit werkt alleen als de server byte-range requests ondersteunt. Accept-Ranges: bytes is een nuttige positieve aanwijzing, maar de afwezigheid daarvan bewijst niet dat ranges niet ondersteund worden. De betrouwbare test is het antwoord van de server op een echte range request: een hervatbare response geeft normaal 206 Partial Content terug met een geldige Content-Range. Draai het hervatcommando en inspecteer de status met -v of -D -; als de server de range negeert of de offset afwijst, begin dan bewust opnieuw in plaats van te veronderstellen dat het gedeeltelijke bestand veilig is.
Stap 4: Download met voortgangsbalk of juist stil
Voor een nettere weergave in een interactieve terminal: curl -# -LO <url>. Voor scripts en cronjobs waar je alleen fouten wilt zien, niet alle ruis: curl -sS -LO <url>. Ik gebruik de stille versie bijna overal, behalve wanneer ik handmatig debug.
Stap 5: Beperk de downloadsnelheid
Op een gedeelde kantoorverbinding (of als ik niet die persoon wil zijn die alle bandbreedte opeet tijdens een videocall) beperk ik de snelheid met:
curl --limit-rate 1M -LO https://example.com/big-dataset.zip
De units zijn K, M en G voor kilobytes, megabytes en gigabytes per seconde.
Stap 6: Sla responseheaders op naast het bestand
Soms wil ik precies weten wat de server terugstuurde — content type, cache headers, dat soort dingen — zonder mijn terminal te vervuilen:
curl -L -D headers.txt -o file.zip https://example.com/file.zip
Dit zet de responseheaders in headers.txt, terwijl het echte bestand naar file.zip gaat. Ideaal om content-type-mismatches te debuggen of te controleren of een CDN echt cachet wat je denkt dat hij cachet.
Tips en veelvoorkomende valkuilen
- Tip: Gebruik standaard altijd
-L. Ik kan eerlijk gezegd geen nadeel bedenken aan het toevoegen ervan, en ik heb al uren verloren doordat ik het vergat. - Tip: Combineer in scripts
--failmet je downloadcommando, zodat een niet-2xx-response het script echt laat stoppen met een fout, in plaats van stilletjes een foutpagina op te slaan alsof het je bestand was. - Valkuil: Combineer
-C -niet met--remove-on-error— curl documenteert deze opties als incompatibel, omdat hervatten vereist dat het gedeeltelijke bestand nog aanwezig is. - Valkuil:
-Okan bestanden zonder waarschuwing overschrijven. Als je batch-downloads in een gedeelde map doet, gebruik dan--output-dirom alles netjes af te schermen.
Hoe je meerdere bestanden en batch-downloads doet met cURL
Voorbeelden met één bestand zijn het makkelijke deel. De echte workflows die ik heb gebouwd — nachtelijke data-exports ophalen, binaries synchroniseren over buildservers — hadden concurrency nodig, en daar stoppen de meeste tutorials gewoon... abrupt. Er zijn drie benaderingen die je moet kennen, elk een stap verder in complexiteit.
Benadering 1: Meerdere URL’s in één cURL-commando
De simpelste optie is gewoon URL’s opsommen:
curl -LO https://example.com/a.zip -LO https://example.com/b.zip -LO https://example.com/c.zip
Dit werkt, maar het is sequentieel — curl voltooit eerst het ene bestand volledig voordat het aan het volgende begint. Prima voor drie bestanden, pijnlijk voor driehonderd.
Benadering 2: Parallel downloaden met --parallel (curl 7.66+)
Sinds curl 7.66 kun je --parallel (of -Z) toevoegen om meerdere URL’s tegelijk op te halen:
curl --parallel --parallel-max 5 --remote-name-all \
https://example.com/a.zip https://example.com/b.zip https://example.com/c.zip
Goed om te weten: de standaardwaarde voor parallel max is eigenlijk 50, en dat is flink meer gelijktijdige verbindingen dan de meeste servers — of je eigen netwerk — zullen waarderen. Ik maak --parallel-max daarom expliciet en conservatief, meestal 4 tot 8, in plaats van op de standaard te vertrouwen.
Benadering 3: xargs en Bash-loops voor concurrency vanuit een URL-lijst
Voor een grote lijst URL’s in een tekstbestand pak ik meestal xargs:
cat urls.txt | xargs -n1 -P 8 curl -O -L
Of, als ik meer controle wil over wat er per taak gebeurt, een Bash-loop met achtergrondprocessen:
while read -r url; do
curl -O -L "$url" &
done < urls.txt
wait
De wait aan het einde is belangrijk — zonder dat commando verlaat je script de boel voordat de achtergrond-downloads klaar zijn.
Wanneer je beter wget of aria2 kunt gebruiken
Ik ben er eerlijk over: cURL is niet altijd de juiste tool. Als je een volledige website of mapstructuur wilt spiegelen, doet wget -r recursieve crawling out-of-the-box op een manier waarvoor cURL simpelweg niet gebouwd is. Als je multi-source, gesegmenteerde downloads wilt voor maximale doorvoer bij één enorm bestand, is aria2c echt sneller.
| Tool | Het meest geschikt voor |
|---|---|
| cURL | Precisie, scripting, downloads van één bestand of kleine batches, API-interactie |
| wget | Recursieve of gespiegeld website-downloads, eenvoudige bulk-ophaling van statische bestanden |
| aria2 | Multi-source/gesegmenteerde downloads, maximale throughput bij grote bestanden |
De kracht van cURL zit altijd in precisie en combineerbaarheid — piping, scripting, protocol-flexibiliteit — niet in brute-force crawling.
Hoe je beveiligde bestanden downloadt met cURL: authenticatiepatronen
De meeste cURL-tutorials stoppen bij -u user:pass en noemen het een dag. Dat is een overblijfsel uit een ouder internet. In 2026 komen de bestanden die ik echt download uit REST API’s, dashboards met sessies en CI-systemen — en elk daarvan vraagt om een ander type credential.
Basic Auth
curl -u username:password -O https://legacy-server.example.com/file.zip
Prima voor ouderwetse FTP-servers of simpele HTTP-endpoints. Bedenk wel dat het wachtwoord in je shell history en process list verschijnt als je niet oppast — niets wat ik voor iets gevoeligs zou gebruiken.
Bearer- / OAuth-tokenauthenticatie
Dit is er een die in de meeste handleidingen onderbelicht blijft, terwijl ik hem juist het vaakst gebruik:
curl -H "Authorization: Bearer $GITHUB_TOKEN" \
-LO https://api.github.com/repos/curl/curl/releases/assets/12345
Dat is een echt patroon om een privé GitHub-release asset op te halen — vervang gewoon je token en asset-ID. REST API’s en OAuth2-beveiligde resources spreken tegenwoordig vrijwel allemaal deze taal.
Cookie-gebaseerde sessieauthenticatie
Voor webapps waarbij inloggen een sessie creëert, sla je de cookie jar op bij het inloggen en hergebruik je die bij de download:
curl -c cookies.txt -d "user=me&pass=secret" https://example.com/login
curl -b cookies.txt -O https://example.com/protected/file.zip
.netrc-bestand voor scripts en CI-omgevingen
Mijn voorkeursmethode voor alles wat onbemand draait. Maak een ~/.netrc-bestand aan (of _netrc op Windows):
machine example.com
login myusername
password mypassword
Beveilig het met chmod 600 ~/.netrc, en verwijs er vervolgens naar met:
curl --netrc -LO https://example.com/protected-file.zip
Het voordeel is dat je inloggegevens nooit in je shell history of scriptbroncode terechtkomen — echt belangrijk in CI/CD, waar scripts vaak volledig worden gelogd.
| Auth-methode | Flag/optie | Het best voor |
|---|---|---|
| Basic auth | -u user:pass | Legacy FTP, simpele HTTP |
| Bearer token | -H "Authorization: Bearer <token>" | REST API’s, OAuth2 |
| Cookie-auth | -b cookies.txt (+ -c om op te slaan) | Sessiegebaseerde webapps |
.netrc-bestand | --netrc of --netrc-file | CI/CD, gescripte omgevingen |
Problemen oplossen bij veelvoorkomende cURL-downloadfouten
Dit is de sectie die ik zelf graag had gehad toen ik begon, want bijna niemand behandelt dit goed. "Waarom werkt mijn curl-download niet" is een echte, veelvoorkomende en frustrerende zoekvraag — en de oplossingen zijn meestal één regel zodra je de oorzaak kent.
| Symptom | Waarschijnlijke oorzaak | Oplossing |
|---|---|---|
curl: (60) SSL certificate problem | Zelfondertekend of verlopen certificaat | --cacert <bestand> of -k (alleen dev) |
403 Forbidden / leeg bestand | Server blokkeert de standaard curl User-Agent | -A "Mozilla/5.0..." of -H "User-Agent: ..." |
Download begint opnieuw vanaf 0 met -C - | Server ondersteunt Range niet | Check met curl -I <url> op Accept-Ranges: bytes |
| 0-byte bestand opgeslagen | Redirect niet gevolgd | Voeg de -L flag toe |
curl: (28) Operation timed out | Trage server of netwerkproblemen | --connect-timeout 10 --max-time 300 + --retry 3 |
| HTML-pagina opgeslagen in plaats van bestand | Pagina vereist JavaScript-rendering | curl kan geen JS uitvoeren — zie de sectie hieronder |
SSL-certificaatfouten: wat ze betekenen en hoe je ze oplost
Fout 60 betekent dat curl het SSL-certificaat van de server niet kon verifiëren — meestal omdat het zelfondertekend, verlopen of uitgegeven door een CA is die curl niet vertrouwt. Als jij de server beheert, wijs curl dan naar de juiste CA-bundel met --cacert /path/to/ca.pem. De -k (--insecure)-flag slaat verificatie volledig over; prima in een lokale ontwikkelomgeving, maar echt een slecht idee voor alles wat productie of echte gebruikersdata raakt.
403 Forbidden en lege downloads
Een verrassend groot aantal servers blokkeert requests die zichzelf identificeren als curl/8.21.0 (de standaard User-Agent-string van curl), omdat ze aannemen dat het bots of scrapers zijn. De oplossing is meestal simpelweg doen alsof je een browser bent:
curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -LO https://example.com/file.zip
Om te checken wat er echt terugkomt voordat je een volledige download doet, gebruik ik: curl -o /dev/null -s -w "%{http_code}\n" <url>.
Time-outs, retries en instabiele verbindingen
Dit is het commando dat ik op mijn arm zou tatoeëren als ik moedig genoeg was voor tatoeages.
Mijn standaard downloadcommando, het commando dat ik echt in productiescripts gebruik, combineert alle betrouwbaarheidsflags:
curl -L -C - --retry 5 --retry-delay 3 --connect-timeout 10 --max-time 600 --fail -O <url>
Dat betekent redirects volgen, hervatten, vijf retries met 3 seconden wachttijd, een connect-timeout van 10 seconden, een totale limiet van 10 minuten en een harde fout bij een slechte HTTP-status — eigenlijk alles wat ik na veel vallen en opstaan ben gaan opnemen.
cURL in echte automatisering: CI/CD-pipelines, piping en veilige scripts
cURL-output doorgeven aan andere tools
curl hoeft niets per se op schijf op te slaan — direct doorgeven aan een ander commando is een van de meest onderschatte functies:
curl -sL https://example.com/archive.tar.gz | tar xz
curl -s https://api.example.com/data | jq '.results'
Downloaden en uitpakken, of downloaden en parsen, in één regel. Dit is het patroon dat ik constant gebruik voor eenmalige data-ophalingen.
cURL gebruiken in GitHub Actions en CI/CD
Een minimale GitHub Actions-step die een binary downloadt met retry-logica en luid faalt bij fouten:
- name: Download binary
run: |
curl -L --fail --retry 3 --retry-delay 5 \
-o app-binary "https://example.com/releases/app-binary"
Bewaar tokens als CI-secrets en verwijs ernaar via environment variables — hardcode ze nooit in het script zelf. En gebruik --fail (of --fail-with-body als je de foutbody nodig hebt voor debugging), zodat een kapotte download de build ook echt laat falen in plaats van stilletjes succesvol te lijken met rommel.
De curl | sh-veiligheidskwestie
Deze vraag komt in bijna elk ontwikkelaarsforum voorbij dat ik heb gelezen, en terecht: curl direct naar sh pipen betekent dat je remote code uitvoert die je niet hebt bekeken, volledig gebaseerd op vertrouwen dat de server niet gecompromitteerd is en de verbinding niet is aangepast. Dat is het echte risico — niet paranoia, gewoon een heel concrete supply-chain zorg.
De veiligere aanpak is: eerst downloaden, het script bekijken, een checksum of GPG-handtekening verifiëren als die beschikbaar is, en pas daarna uitvoeren:
curl -sL https://example.com/install.sh -o install.sh
cat install.sh # lees het echt even
sha256sum install.sh # vergelijk met de gepubliceerde checksum als die er is
bash install.sh
Bekende installerders zoals rustup en Homebrew gebruiken nog steeds het curl | sh-patroon, en dat wordt in die specifieke gevallen meestal geaccepteerd omdat de maintainers en distributieketen goed ingeburgerd zijn. Toch kijk ik liever nog even tien seconden extra naar een script dan er later achter te komen dat ik het niet had moeten vertrouwen.
Wanneer cURL niet genoeg is: JavaScript-gerenderde pagina’s, anti-bot-sites en gestructureerde data
Hier zit een foutmodus waar veel mensen tegenaan lopen, en het is zelden hun schuld: je draait curl -O op wat eruitziet als een normale pagina, en in plaats van de inhoud die je verwacht, krijg je een lege HTML-schaal, een Cloudflare-challengepagina of iets dat eruitziet als rommel. cURL deed precies wat het moest doen — de ruwe HTTP-response ophalen — maar het kan geen JavaScript uitvoeren, geen CAPTCHA oplossen en niet door een anti-bot fingerprinting-systeem heen komen. Dat zijn geen bugs in cURL; dat valt gewoon buiten zijn takenpakket.
Waarom cURL faalt op moderne webpagina’s
Moderne single-page apps leveren vaak een bijna lege HTML-skeleton terug, waarbij de echte inhoud pas client-side door JavaScript wordt gerenderd nadat de pagina geladen is — iets wat curl nooit uitvoert. Daarbovenop serveren systemen zoals Cloudflare en Akamai actief challengepagina’s aan alles wat niet op een echte browser lijkt, en herhaalde curl-requests vanaf hetzelfde IP kunnen al snel gerate-limited worden of als botverkeer worden gefingerprinted.
De volgende stap: AI-scraping-API’s voor developers
Ik zou zeggen dat curl de juiste tool is voor ongeveer 80% van alle bestand- en data-downloads — statische assets, API-responses, alles wat als een gewone HTTP-resource wordt aangeboden. Het is die andere 20%, de JavaScript-zware of bot-beveiligde pagina’s, waar ik developers uren heb zien worstelen met headers en User-Agent-strings voordat ze uiteindelijk toch naar een andere laag zijn uitgeweken.
Precies die kloof wilde mijn team dichten met Thunderbit, naast de Chrome-extensie waar de meeste mensen ons van kennen. Aan de developer-kant geeft Thunderbit’s Open API je POST /distill, dat schone, LLM-ready Markdown teruggeeft vanaf een URL — waarbij het renderen van de pagina door de service wordt afgehandeld — en POST /extract, dat schema-gebonden gestructureerde JSON teruggeeft wanneer je echte velden nodig hebt in plaats van leesbare tekst. Er is ook een MCP-server zodat agents in Claude of Cursor tijdens een taak thunderbit_distill en thunderbit_extract kunnen aanroepen, en een CLI (npx @thunderbit/thunderbit-cli distill <url>) die in je terminal veel op curl voelt. Pipe JSON-output bijvoorbeeld naar jq: thunderbit distill <url> --format json | jq -r '.data.markdown'; stuur --format markdown-output desnoods naar een teksttool of direct naar een bestand.
Naast elkaar zie je het verschil meteen. Een curl-request op een JavaScript-gerenderde productpagina kan een grotendeels lege <div id="root"></div> teruggeven. Het equivalente thunderbit distill-commando levert gerenderde pagina-inhoud als nette Markdown. Distill kost 1 credit per URL en Extract 20 credits per URL. De huidige limieten per endpoint verschillen: Batch Distill ondersteunt tot 100 URL’s per job, terwijl Batch Extract tot 50 URL’s met één gedeeld schema accepteert. Check de huidige API-documentatie voordat je een productiewachtrij gaat dimensioneren.
Als je nieuw bent met het onderwerp in het algemeen, is onze eigen uitleg over wat web scraping precies inhoudt een goed startpunt, en de no-code scraping gids behandelt de niet-technische kant van hetzelfde probleem voor iedereen in je team die liever geen terminal aanraakt. Voor een bredere vergelijking van tools in deze ruimte hebben we ook een overzicht gemaakt van de beste AI webscrapers die je zou moeten kennen.
Snelle referentie: cURL-download-spiekbrief
| Taak | Commando |
|---|---|
| Basisdownload | curl -LO <url> |
| Aangepaste bestandsnaam | curl -L -o mijnbestand.zip <url> |
| Download hervatten | curl -C - -LO <url> |
| Stil, maar met fouten zichtbaar | curl -sSL -O <url> |
| Parallel downloaden | curl --parallel --parallel-max 5 -O <url1> -O <url2> |
| Bearer-tokenauthenticatie | curl -H "Authorization: Bearer <token>" -LO <url> |
| Standaard script-download | curl -LO --retry 5 --retry-delay 3 --max-time 600 --fail <url> |
| Doorsturen naar extraction tool | curl -sL <url> | tar xz |
Conclusie en belangrijkste inzichten
Een bestand downloaden met curl begint simpel — curl -O en je bent grotendeels klaar — maar de echte vaardigheid zit in de lagen eronder: weten wanneer je -L moet toevoegen, wanneer je beter kunt hervatten dan opnieuw beginnen, welk authenticatiepatroon echt bij je workflow past en wat je moet doen zodra er ineens een 403 of een leeg HTML-skelet verschijnt in plaats van het bestand dat je verwachtte. Ik heb op elk van deze patronen op een gegeven moment moeten vertrouwen, meestal vlak nadat ik op de harde manier had geleerd waarom het ertoe deed.
curl blijft zonder twijfel mijn standaardtool voor eenvoudige bestanddownloads en scriptbare HTTP-werkzaamheden — snel, overal beschikbaar en prachtig te combineren met de rest van een shell-pipeline. Maar zodra je een JavaScript-gerenderde pagina of een anti-botmuur raakt, is dat geen cURL-probleem dat je oplost met nog meer flags; dat betekent dat je een andere laag nodig hebt, en precies daar pakt een API zoals die van Thunderbit het werk op zonder je uit je terminal te dwingen.
Bookmark de spiekbrief, probeer het retry-en-resume-commando eens op je volgende instabiele download, en als je die muur raakt waar curl alleen nog rommel teruggeeft, weet je wat de volgende stap is — op de pricing-pagina van Thunderbit vind je de actuele creditverdeling als je wilt zien wat zo’n escalatie daadwerkelijk kost, en ons YouTube-kanaal heeft walkthroughs als je liever kijkt dan leest.
FAQ’s over bestanden downloaden met cURL
Hoe download ik een bestand met cURL en sla ik het op met een specifieke naam?
Gebruik -o gevolgd door de gewenste bestandsnaam: curl -L -o jouwnaam.ext <url>. Voeg -L toe zodat redirects de download niet saboteren.
Hoe hervat ik een mislukte cURL-download?
Voer curl -C - -LO <url> uit. Dit werkt alleen als de server range requests ondersteunt — controleer eerst met curl -I <url> en kijk in de response naar Accept-Ranges: bytes.
Kan cURL bestanden downloaden waarvoor je moet inloggen?
Ja, op vier belangrijke manieren: basic auth (-u user:pass), bearer tokens (-H "Authorization: Bearer <token>"), sessies op basis van cookies (-b cookies.txt) of een .netrc-bestand voor gescripte omgevingen. Zie de authenticatiesectie hierboven voor de volledige uitleg en wanneer welke methode past.
Wat is het verschil tussen cURL en wget voor het downloaden van bestanden?
cURL ondersteunt meer protocollen en is doorgaans beter voor scripting, piping en precieze downloads van één bestand of kleine batches. wget is gebouwd voor recursieve crawling en het spiegelen van volledige websitemappen, en is daardoor de betere keuze voor bulk-downloads van statische sites.
Waarom downloadt cURL een HTML-pagina in plaats van het echte bestand?
Twee gebruikelijke oorzaken: je bent de -L-flag vergeten en de server heeft je doorgestuurd naar ergens anders, of de pagina heeft JavaScript nodig om de echte inhoud te renderen — iets wat curl simpelweg niet kan uitvoeren. In het tweede geval heb je een tool nodig die kan renderen, niet nog meer cURL-flags.
