Duas ferramentas de linha de comandos que, ambas, descarregam ficheiros via HTTP, instaladas em quase todas as máquinas, constantemente comparadas e raramente distinguidas de forma útil.
A fonte mais fiável sobre a diferença é, felizmente, a comparação publicada pelo próprio mantenedor do curl — um documento que inclui uma secção explícita sobre o que o wget faz melhor do que o curl. Todas as afirmações factuais abaixo têm origem nesse documento ou nos próprios manuais dos projetos, em vez de se basearem na impressão de alguém, o que é importante numa comparação frequentemente feita de memória.
Somos a Geonode, vendemos proxies, e a nota de honestidade é curta: nenhuma das ferramentas precisa de um proxy para a grande maioria das utilizações que as pessoas lhes dão. Obter um ficheiro, chamar uma API, verificar se um serviço responde — nada disso requer um proxy. Existe uma diferença genuína e pouco documentada entre as duas no que diz respeito ao suporte a proxies, e há uma secção sobre isso mais abaixo, mas se chegou aqui a tentar escolher um programa de download, pode ignorá-la sem problemas.
O resumo útil é que estas ferramentas foram criadas com modelos mentais diferentes, e quase todas as diferenças visíveis decorrem disso. O curl comporta-se como cat — obtém algo e escreve-o na saída padrão. O wget comporta-se como cp — obtém algo e escreve-o num ficheiro. Essa é a própria perspetiva do mantenedor e, uma vez compreendida, os comportamentos por predefinição dos redirecionamentos, as diferenças entre os sinalizadores e a capacidade de recursão deixam de ser arbitrárias.
A recomendação resumida, para quem a quiser antes dos detalhes: usa o wget quando quiseres ficheiros no disco e o curl para tudo o resto.
A diferença de uma única frase
O curl funciona, nas palavras do seu mantenedor, «como o comando tradicional do Unix cat
». O wget funciona «mais como cp
».
Essa única distinção explica a maior parte do que se segue.
O que isso significa na prática
curl https://example.com/file.txt # prints the contents to your terminal
wget https://example.com/file.txt # saves file.txt to the current directory
Nenhum dos dois está errado. Estão a responder a perguntas diferentes.
O design do curl parte do princípio de que queres os dados e que o que acontece a seguir com eles é da tua conta — encaminhá-los, analisá-los, redirecioná-los, lê-los. Escrever na saída padrão é a escolha mais flexível, e é por isso que o curl se encaixa naturalmente nos pipelines do shell.
O design do wget parte do princípio de que o utilizador quer o ficheiro. Ele escolhe o nome do ficheiro, cria-o, mostra uma barra de progresso e termina com algo no disco.
Por que razão as consequências são maiores do que parecem
Quando a função de uma ferramenta é «colocar o ficheiro no disco», todo um conjunto de comportamentos torna-se obviamente correto: seguir redirecionamentos, porque o ficheiro mudou de local; tentar novamente em caso de falha, porque o objetivo é o ficheiro e não a tentativa; retomar um download parcial, porque metade de um ficheiro não é o que se pretende. O wget faz tudo isto por predefinição.
Quando a função de uma ferramenta é «efectuar esta transferência e dar-me o resultado», os comportamentos corretos são diferentes: relatar o que aconteceu em vez de decidir por mim, fazer exatamente o que foi pedido e deixar que quem a chamou trate do resto. O curl relata o redirecionamento e pára, porque segui-lo não era o que pediste.
Nenhum dos dois conjuntos de comportamentos por predefinição é melhor. São consistentes com finalidades diferentes, e grande parte da frustração que as pessoas sentem com qualquer uma das ferramentas advém de esperarem as premissas da outra.
O que o curl faz e o wget não
De acordo com a comparação feita pelo responsável pela manutenção, e trata-se de uma lista substancial.
É, antes de mais, uma biblioteca
O curl inclui a libcurl, descrita como tendo «uma API estável que pode ser utilizada por todos». Esta é a diferença mais significativa e a menos visível a partir de um terminal.
A libcurl está incorporada numa enorme quantidade de software — ligações de linguagens, aplicações, dispositivos. A ferramenta de linha de comandos é, de certa forma, uma demonstração da biblioteca. O wget é um programa; o curl é um programa construído sobre uma biblioteca que outros programas utilizam.
Se já utilizou as funções cURL do PHP ou uma ligação HTTP de uma linguagem de programação baseada na libcurl, já utilizou o curl sem executar o curl.
Muito mais protocolos
A lista publicada é extensa: «FTP(S), GOPHER(S), HTTP(S), SCP, SFTP, TFTP, TELNET, DICT, LDAP(S), MQTT, FILE, POP3(S), IMAP(S), SMB(S), SMTP(S), RTMP, RTSP e WS(S)».
O wget suporta HTTP, HTTPS e FTP. Para a Web, isso costuma ser suficiente. Para qualquer coisa que envolva protocolos de e-mail, SFTP, MQTT ou WebSocket, o curl é o único dos dois a entrar em cena.
Versões mais recentes do HTTP
O curl suporta HTTP 0.9, 1.0, 1.1, 2 e 3. Se precisar de testar especificamente o comportamento de um servidor com HTTP/2 ou HTTP/3, essa é uma tarefa para o curl.
Mais tipos de proxy
O curl suporta proxies HTTPS, SOCKS4 e SOCKS5. Isto está incluído entre as funcionalidades que o curl possui e que o wget não tem, e tem consequências reais — consulte a secção sobre proxies abaixo.
Transferências paralelas
O curl pode executar várias transferências simultâneas com a opção -Z. Útil ao recuperar muitos recursos pequenos, em que a latência de os processar um de cada vez é predominante.
Transferência bidirecional e envios de formulários
Enviar dados, não apenas recebê-los. Envios de formulários multiparte, PUT, métodos arbitrários. O wget é, fundamentalmente, uma ferramenta de recuperação; o curl é uma ferramenta de transferência, e os envios são um caso de primeira classe.
Já está instalado em mais máquinas
O curl vem pré-instalado no macOS e no Windows 10 e 11. Numa máquina Windows sem nada adicionado, o curl está disponível e o wget, geralmente, não — o que tem mais importância do que deveria para scripts multiplataforma.
O que o wget faz e o curl não
Também do próprio mantenedor do curl, o que torna esta lista digna de confiança.
Transferência recursiva
«O principal ponto forte do wget em comparação com o curl é a sua capacidade de efetuar transferências de forma recursiva.»
Esta é a grande diferença e não é uma funcionalidade insignificante. O wget consegue seguir links a partir de uma página e descarregar o que encontrar, até uma profundidade especificada, convertendo os links para visualização local à medida que avança. Criar um espelho de um site de documentação para leitura offline é feito com um único comando.
wget -r -np -k -p https://example.com/docs/
Recursivo, sem diretórios pai, converte links para visualização local, obtém elementos necessários da página, como imagens e folhas de estilo.
O curl não consegue fazer isto de todo. O curl obtém os URLs que lhe forneces. Não analisa HTML, não descobre links e não tem noção do que é um site. Se a sua tarefa for «copiar esta secção de um site», o wget é a resposta e não existe nenhum equivalente no curl que valha a pena experimentar.
Retomar transferências interrompidas
O wget «consegue recuperar de uma transferência interrompida prematuramente e continuar o download». Com -c, um download interrompido retoma a partir do ponto em que parou.
O curl também consegue fazer isto com -C -, mas o comportamento do wget em relação a novas tentativas e retomadas é mais automático e mais tolerante — o que é importante quando a transferência é grande e a ligação não é fiável.
Não Precisa de Opções para o Caso Óbvio
O wget descarrega um ficheiro sem opções. O curl «precisa de -o ou -O» para gravar num ficheiro em vez de no terminal.
Para a tarefa mais comum que qualquer pessoa realiza com qualquer uma das ferramentas — descarregar este ficheiro —, o wget é o comando mais curto, e ser mais curto é uma vantagem real numa ferramenta que se usa diariamente.
Predefinições mais sensatas para o download
O wget «ativa mais funcionalidades por predefinição: cookies, seguimento de redirecionamentos e marcação temporal».
A marcação temporal merece uma menção especial: com a opção «-N», o wget só volta a descarregar um ficheiro se a versão remota for mais recente. Para a sincronização agendada de um conjunto de ficheiros, este é exatamente o comportamento adequado e o curl não tem nenhum equivalente direto.
Licença
O wget está sob a licença GPL v3; o curl está sob a licença MIT. Se estiver a integrar qualquer um deles num produto, essa diferença provavelmente será mais importante do que qualquer funcionalidade mencionada nesta página.
Configurações predefinidas que lhe fazem perder tempo
As diferenças mais suscetíveis de lhe causar uma tarde de confusão.
Redirecionamentos
O wget segue os redirecionamentos por predefinição. O curl não.
Esta é a causa mais comum para a pergunta «por que é que o curl não devolveu nada?». O servidor respondeu com um 301, o curl comunicou isso e parou, e a saída padrão parece vazia.
curl -L https://example.com/moved # follow them
wget https://example.com/moved # already following them
Não se trata de um lapso do curl. Seguir um redirecionamento significa efetuar um pedido que não foi solicitado, para um anfitrião que não foi especificado, e o modelo do curl é fazer o que lhe foi pedido e reportar o resto. O modelo do wget é obter o ficheiro, e o ficheiro foi movido.
Destino da saída
Já abordado acima, mas vale a pena repetir porque confunde constantemente as pessoas. curl URL imprime; wget URL guarda.
Tratamento de erros
Ambos têm uma peculiaridade. O curl trata um 404 como uma transferência bem-sucedida e sai com código zero — a transferência funcionou, o servidor respondeu. Use -f para fazer com que os erros HTTP produzam um código de saída diferente de zero.
O wget, por predefinição, termina com um valor diferente de zero em caso de erros HTTP, o que é o comportamento mais intuitivo para um programa de transferência.
Em scripts: curl -sSf é a combinação que vale a pena lembrar, e a sua ausência é uma razão comum para que uma tarefa com falha pareça estar a funcionar.
Novas tentativas
O wget tenta novamente por predefinição. O curl não o faz, a menos que se solicite com --retry.
Mais uma vez, em consonância com os modelos: um programa de transferência deve persistir, uma ferramenta de transferência deve reportar.
O conselho prático
Se estiver a escrever qualquer código automatizado, defina o comportamento explicitamente, em vez de confiar nos valores predefinidos de qualquer uma das ferramentas. curl -sSfL --max-time 30 indica o que pretende. O mesmo acontece com wget --tries=3 --timeout=30. Os comandos explícitos sobrevivem à leitura por outra pessoa daqui a um ano.
Lado a lado
| Tarefa | curl | wget |
|---|
| Imprimir no terminal | curl URL | wget -O - URL |
| Guardar num ficheiro | curl -O URL | wget URL |
| Guardar com o nome escolhido | curl -o name URL | wget -O name URL |
| Seguir redirecionamentos | curl -L URL | predefinido |
| Retomar um download | curl -C - -O URL | wget -c URL |
| Apenas cabeçalhos | curl -I URL | wget --spider -S URL |
| Cabeçalho personalizado | curl -H "K: V" URL | wget --header="K: V" URL |
| Autenticação básica | curl -u user:pass URL | wget --user=u --password=p URL |
| Dados POST | curl -d "a=b" URL | wget --post-data="a=b" URL |
| Silencioso | curl -s URL | wget -q URL |
| Espelhar um site | não é possível | wget -m URL |
| Carregar um ficheiro | curl -T file URL | não é possível |
| Utilizar o SOCKS5 | curl -x socks5h://host URL | não nativamente |
| Transferências paralelas | curl -Z ... | não suportado |
Como interpretar a tabela
A simetria mantém-se nas operações do dia-a-dia — a maioria das tarefas tem um equivalente direto, com variações na ortografia dos sinalizadores que são mais incómodas do que importantes.
As quatro linhas marcadas como «impossíveis» são onde a escolha é realmente feita. O espelhamento de um site é feito apenas com o wget. O upload é feito apenas com o curl. A utilização de proxy SOCKS é feita apenas com o curl. As transferências paralelas são feitas apenas com o curl.
Se a sua tarefa estiver numa dessas linhas, a comparação termina aqui e pode parar de ler. Caso contrário, qualquer uma das ferramentas funciona e deve utilizar aquela com a qual se sente mais à vontade.
Uma nota sobre a colisão de opções
«-O» tem significados diferentes nas duas ferramentas, o que constitui uma verdadeira armadilha.
No curl, -O significa «guardar utilizando o nome de ficheiro da URL» e -o name significa «guardar com este nome». No wget, -O name significa «guardar com este nome» e não há necessidade da outra opção.
Portanto, curl -O e wget -O não são equivalentes, e um comando traduzido descuidadamente entre as duas ferramentas resultará em algo inesperado.
Qual utilizar consoante a tarefa
Uma lista de orientações, em vez de uma conclusão definitiva.
Utilize o wget quando
Quer um ficheiro no disco. Sem opções, com barra de progresso e predefinições sensatas. Este é o caso mais comum para a maioria das pessoas.
Quer fazer um espelhamento ou um download recursivo. É a única opção. wget -m ou wget -r com limites adequados.
A ligação não é fiável e o ficheiro é grande. Tentativas automáticas e retomada -c.
Está a manter uma cópia local sincronizada. -N com marcação temporal, descarrega apenas o que foi alterado.
Pretende o comando mais curto possível para um download simples num script que outra pessoa irá ler.
Utilize o curl quando
Estiver a trabalhar com uma API. Cabeçalhos, métodos, corpos de pedidos e saída que é canalizada para um processador JSON.
Precisa de enviar dados, não apenas de os recuperar.
Está a depurar. -v e -w mostram-lhe a solicitação tal como foi enviada, a resposta e o tempo de execução desagregado por fase. Esta é, de longe, a maior vantagem do curl no dia a dia.
Precisa de um protocolo além do HTTP e do FTP.
Precisa de suporte a proxies SOCKS ou HTTPS.
Está no Windows ou no macOS sem nada instalado, onde o curl está presente e o wget normalmente não está.
Está a escrever algo que se tornará código, uma vez que as ligações da libcurl fazem com que a estrutura do comando se traduza naturalmente.
Use os dois
A resposta honesta para a maioria das configurações de trabalho. São pequenos, são gratuitos e são bons em coisas diferentes. Ter os dois instalados e escolher aquele que se adequa melhor não é indecisão — é o resultado correto de serem ferramentas genuinamente diferentes.
Proxies em ambos
O nosso território, e há uma diferença real que vale a pena conhecer.
curl
# HTTP proxy
curl -x http://proxy.example.com:8080 https://example.com
# With credentials
curl -x http://user:pass@proxy.example.com:8080 https://example.com
# SOCKS5, with the proxy resolving hostnames
curl -x socks5h://proxy.example.com:1080 https://example.com
O curl suporta proxies HTTP, proxies HTTPS e SOCKS4/SOCKS5
, tudo através da mesma opção -x
com um esquema.
wget
# Via environment variables
export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"
wget https://example.com
# With credentials
wget --proxy-user=user --proxy-password=pass https://example.com
O wget lê as variáveis de ambiente padrão de proxy e dispõe de opções para credenciais de proxy.
A diferença que importa
O wget não tem suporte nativo para SOCKS. A comparação do curl lista SOCKS4 e SOCKS5
entre as funcionalidades que o curl suporta e o wget não.
Se o seu proxy for apenas SOCKS, o wget não o pode utilizar diretamente. As soluções alternativas habituais consistem em executar o wget através de uma ferramenta como o proxychains ou em colocar uma ponte local HTTP-para-SOCKS à sua frente — ambas funcionam, mas ambas adicionam um componente que pode falhar sem aviso prévio.
Se estiver a escolher entre as duas opções e o SOCKS estiver na sua configuração, isso decide a questão.
O detalhe do DNS, mais uma vez
Vale a pena repetir, porque se aplica sempre que o curl é utilizado com SOCKS. socks5://
resolve nomes de host na sua máquina; socks5h://
envia o nome de host para o proxy. A primeira opção revela todos os hosts que visita ao seu resolvedor local, mesmo que o tráfego seja encaminhado corretamente, e pode fornecer-lhe um endereço regionalmente incorreto para sites com infraestrutura dependente da localização.
Utilize socks5h://
, a menos que tenha uma razão específica para não o fazer.
E a parte em que nos convencemos a desistir de uma venda
Se estiver a descarregar um ficheiro, a aceder a uma API para a qual possui credenciais ou a verificar se um serviço está ativo, não precisa de nenhum proxy. Os proxies justificam a sua existência nestas ferramentas para a verificação geográfica e para trabalhos de grande volume sujeitos a limites de tráfego por endereço. Em todas as outras situações, acrescentam latência, um ponto de falha e uma fatura.
Quando nenhuma das duas é a ferramenta certa
Várias situações comuns exigem outra abordagem, e recorrer a qualquer uma dessas ferramentas é um desperdício de uma tarde.
A página é renderizada por JavaScript. Ambas as ferramentas recuperam o que o servidor envia. Se o conteúdo for montado posteriormente no navegador, obtém-se uma estrutura vazia e nenhuma opção de verificação resolve o problema. Precisa de um navegador sem interface gráfica — Playwright, Puppeteer ou similar.
Precisa de interagir com a página. Clicar, percorrer, preencher formulários, esperar que algo apareça. A resposta é a mesma.
Está a construir algo que possa ser mantido em código. Recorrer ao curl a partir de uma aplicação é um atalho comum que acaba por se tornar obsoleto. Utilize a biblioteca HTTP da sua linguagem de programação ou as ligações da libcurl e obtenha um tratamento de erros adequado.
Precisa de sincronizar um diretório nos dois sentidos. O rsync é a ferramenta ideal e é significativamente melhor nisso do que o wget recursivo.
Está a transferir dados entre servidores que controla. scp, rsync ou sftp — ferramentas criadas especificamente para o efeito, mais rápidas e que gerem corretamente as permissões e as transferências parciais.
Precisa de inspecionar ou modificar o tráfego em trânsito. Uma ferramenta de proxy de interceção é o instrumento certo.
Está a descarregar conteúdos multimédia de uma plataforma de vídeo. As ferramentas específicas para o efeito tratam da análise do manifesto e da montagem do fluxo, algo que nenhuma destas opções faz.
Os dados são disponibilizados de outra forma. Uma API, um descarregamento em massa, um conjunto de dados público, um feed RSS. A verificação demora dez minutos e, frequentemente, põe fim ao projeto antes mesmo de este começar.
A precaução com o download recursivo
Um aviso específico sobre o wget -r, que é poderoso e fácil de direcionar para algo que não pretendia.
Sem -np, pode subir para diretórios pai. Sem --level, pode descer bastante. Sem --wait, irá efetuar pedidos tão rapidamente quanto o servidor responder, o que é uma atitude indelicada em relação à infraestrutura de outrem e uma boa maneira de ser bloqueado.
No mínimo: wget -r -np --level=3 --wait=1 URL. E verifique primeiro robots.txt e os termos do site — o wget respeita robots.txt por predefinição, e desativar isso é uma decisão e não uma mera conveniência.
Perguntas frequentes
Qual é a diferença entre o curl e o wget?
O curl funciona como cat — obtém os dados e escreve-os na saída padrão. O wget funciona como cp — obtém os dados e guarda um ficheiro. O curl suporta muito mais protocolos, uploads, proxies SOCKS e transferências paralelas; o wget consegue fazer downloads recursivos e espelhar sites, algo que o curl não consegue fazer de todo.
O curl é melhor do que o wget?
Nenhum dos dois é melhor. O curl é uma ferramenta de transferência com uma biblioteca subjacente e uma gama de protocolos muito mais ampla; o wget é um programa de transferência com melhores predefinições para transferências e uma capacidade recursiva única. A maioria das pessoas beneficia de ter ambos.
O curl consegue fazer downloads recursivos como o wget?
Não. O curl recupera os URLs que lhe são fornecidos e não analisa HTML nem descobre links. O download recursivo e a criação de cópias espelho de sites são exclusivos do wget, e o próprio mantenedor do curl refere isto como o principal ponto forte do wget.
Por que é que o curl não segue redirecionamentos?
Por design. O curl reporta o que o servidor disse, em vez de efetuar pedidos que não solicitou. Adicione -L para seguir o redirecionamento. O wget segue por predefinição porque o seu objetivo é recuperar o ficheiro, e o ficheiro foi movido.
O que é mais rápido, o curl ou o wget?
Para uma única transferência, a diferença é insignificante — ambos são limitados pela rede. O curl pode executar várias transferências em paralelo com -Z, o que o torna significativamente mais rápido ao obter muitos recursos pequenos.
O wget suporta proxies SOCKS?
Não de forma nativa. O curl suporta proxies SOCKS4, SOCKS5 e HTTPS; o wget utiliza as variáveis de ambiente padrão para proxies HTTP. Para utilizar SOCKS com o wget, é necessário um wrapper, como o proxychains, ou uma ponte local.
Qual devo utilizar num script?
Qualquer um, com opções explícitas. Para APIs e qualquer situação em que seja necessário inspecionar a resposta, curl -sSfL --max-time 30. Para descarregar ficheiros, wget --tries=3 --timeout=30. Não confie nas predefinições de nenhuma das ferramentas na automatização.
O curl ou o wget vêm instalados por predefinição?
O curl vem pré-instalado no macOS e no Windows 10 e 11. O wget é padrão na maioria das distribuições Linux, mas está frequentemente ausente no macOS e no Windows. Para scripts multiplataforma, é mais seguro partir do princípio de que o curl está instalado.
Conclusão
A comparação resolve-se mais rapidamente do que a sua popularidade sugere, porque as duas ferramentas foram concebidas em torno de verbos diferentes.
O curl transfere. O wget descarrega. O curl escreve na saída padrão, como em cat, faz exatamente o que lhe foi pedido e reporta o resto — razão pela qual não segue redirecionamentos, não repete tentativas e necessita de um parâmetro para gravar um ficheiro. O wget grava no disco, como em cp, e tudo o que faz por predefinição decorre do objetivo de, no final, existir um ficheiro.
Quatro capacidades determinam a escolha de forma definitiva e, se a sua tarefa envolver uma delas, o resto da comparação é irrelevante. O download recursivo e o espelhamento de sites são exclusivos do wget — o próprio mantenedor do curl refere-o como o principal ponto forte do wget, e o curl não tem equivalente. Uploads, proxies SOCKS e transferências paralelas são exclusivos do curl.
Fora disso, ambos funcionam, e as diferenças práticas residem na sintaxe dos argumentos e nos valores por predefinição. Tenha cuidado com a colisão «-O» ao converter comandos entre eles, pois significa coisas opostas em cada um. E em qualquer processo automatizado, indique as suas intenções explicitamente em vez de confiar nas suposições de qualquer uma das ferramentas — «curl -sSfL --max-time 30» e «wget --tries=3 --timeout=30» são ambos comandos que continuarão a fazer sentido para quem os ler no próximo ano.
Sobre proxies: nós vendemo-los, mas a maioria das utilizações destas ferramentas não precisa de nenhum. Quando for necessário, o suporte do curl é mais abrangente, e o pormenor que importa mais do que a ferramenta em si é utilizar socks5h:// em vez de socks5://, para que as pesquisas de nomes de anfitrião sigam a mesma rota que o tráfego.
A recomendação sincera é instalar ambos. São pequenos, são gratuitos e a discussão sobre qual é o melhor está resolvida há anos pelo facto de a maioria das máquinas em funcionamento ter ambos.
