How to upload files with wget

Uploading files to HTTP or HTTPS endpoints with wget enables automated log forwarding, configuration backups, and simple API integrations from non-interactive scripts. Using a single command-line client for both downloads and uploads simplifies maintenance on remote servers and minimal Linux installations where heavyweight HTTP tooling is not available. Raw file uploads are especially useful for pushing text logs, JSON documents, or small binary objects to services that accept direct request bodies.

The wget client can transmit file contents as the HTTP request body by using options such as --post-file and --body-file, while --method selects the HTTP verb, for example POST or PUT. Custom headers added with --header control metadata like Content-Type so that servers correctly interpret the uploaded data, and --output-document writes responses to local files for inspection, parsing, or error handling in shell scripts.

These upload options require a recent wget version (1.20 or newer for --method and --body-file) and a server endpoint configured to accept incoming request bodies. Direct uploads of this sort are suited to APIs and simple echo services and are not a replacement for browser-style multipart form submissions. Care is essential when using methods like PUT, which many servers treat as full object replacement, because an incorrectly chosen URL can overwrite existing data.

1. Create a small text file in the working directory to act as the upload payload.

   $ printf 'sample payload from wget\n' > upload-file.txt
   $ ls -l upload-file.txt
   -rw-r--r-- 1 user user 25 Jan 10 04:13 upload-file.txt

   Any existing file can be used instead of upload-file.txt when sending real data.

2. Send the file as an HTTP POST request and capture the JSON response in post-response.json.

   $ wget --post-file=upload-file.txt --header='Content-Type: text/plain' --output-document=post-response.json https://www.example.com/post
   --2026-01-10 04:13:20--  https://www.example.com/post
   Resolving www.example.com (www.example.com)... 203.0.113.50
   Connecting to www.example.com (www.example.com)|203.0.113.50|:443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 89 [application/json]
   Saving to: 'post-response.json'
   
        0K                                                       100% 7.46M=0s
   
   2026-01-10 04:13:20 (7.46 MB/s) - 'post-response.json' saved [89/89]

   The URL https://www.example.com/post is an echo service suitable for testing and can be replaced with an API or upload endpoint in production.

3. Confirm that the request body arrived intact by reading the echoed payload from the JSON response.

   $ jq -r ".data" post-response.json
   sample payload from wget

   The response body should mirror the contents of upload-file.txt for echo-style endpoints.

4. Upload the same file using the HTTP PUT method to simulate object replacement semantics, writing the reply to put-response.json.

   $ wget --method=PUT --body-file=upload-file.txt --header='Content-Type: text/plain' --output-document=put-response.json https://www.example.com/put
   --2026-01-10 04:13:29--  https://www.example.com/put
   Resolving www.example.com (www.example.com)... 203.0.113.50
   Connecting to www.example.com (www.example.com)|203.0.113.50|:443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 75 [application/json]
   Saving to: 'put-response.json'
   
        0K                                                       100% 4.88M=0s
   
   2026-01-10 04:13:29 (4.88 MB/s) - 'put-response.json' saved [75/75]

   Many servers treat PUT requests as full replacements of the object at the target URL, so incorrect paths can overwrite existing data.

5. Verify the echoed payload from the PUT response to confirm the body arrived intact.

   $ jq -r ".data" put-response.json
   sample payload from wget

   Echo endpoints should return the same body contents that were sent by wget.

6. Adjust the Content-Type header for binary uploads by specifying an appropriate media type for the payload.

   $ cp ~/archive.tar.gz ./archive.tar.gz
   $ ls -lh archive.tar.gz
   -rw-r--r-- 1 user user 512K Jan 10 04:13 archive.tar.gz
   $ wget --method=PUT --body-file=archive.tar.gz --header='Content-Type: application/octet-stream' --output-document=put-archive-response.json https://www.example.com/upload/archive
   --2026-01-10 04:14:17--  https://www.example.com/upload/archive
   Resolving www.example.com (www.example.com)... 203.0.113.50
   Connecting to www.example.com (www.example.com)|203.0.113.50|:443... connected.
   HTTP request sent, awaiting response... 200 OK
   Length: 50 [application/json]
   Saving to: 'put-archive-response.json'
   
        0K                                                       100% 1.76M=0s
   
   2026-01-10 04:14:17 (1.76 MB/s) - 'put-archive-response.json' saved [50/50]

   Using the correct Content-Type ensures that APIs and object stores handle files with the expected encoding and validation rules.

7. Confirm the upload endpoint reported the expected payload size.

   $ jq -r ".bytes" put-archive-response.json
   524288

   A successful test typically includes a 200 OK status in the wget output and a response body that confirms the payload size or echoed contents.