Some APIs and object endpoints accept a request body taken directly from a local file instead of a browser-style form upload. In those cases, wget can be enough to send the payload, capture the response, and prove the write succeeded without introducing another client into the workflow.
The relevant options are --post-file for POST requests and the --method plus --body-file pair for other verbs such as PUT. Add --header when the endpoint expects a specific Content-Type, and use --output-document to save the response body for later inspection.
This pattern sends the file contents as the HTTP request body. It does not create a multipart/form-data upload like a browser file form, so it is only appropriate for endpoints that explicitly accept raw text, JSON, or raw bytes in the request body. Browser-style multipart uploads still need a different client.
Steps to upload files with wget:
- Create the local payload file that will be sent as the request body.
$ printf 'sample payload from wget\n' > upload.txt $ ls -l upload.txt -rw-r--r-- 1 user user 25 Mar 27 10:13 upload.txt
This workflow is best for files whose contents should become the full HTTP body, such as plain text, JSON, or API payload fragments.
- Send the file contents with an HTTP POST request and save the server response.
$ wget --post-file=upload.txt \ --header='Content-Type: text/plain' \ --output-document=post-response.json \ https://api.example.net/upload/post --2026-03-27 10:13:20-- https://api.example.net/upload/post Resolving api.example.net (api.example.net)... 203.0.113.50 Connecting to api.example.net (api.example.net)|203.0.113.50|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 220 [application/json] Saving to: 'post-response.json' 0K 100% 52.5M=0s 2026-03-27 10:13:20 (52.5 MB/s) - 'post-response.json' saved [220/220]--post-file reads the file from disk and sends its contents in the POST body exactly as stored.
- Inspect the saved response to confirm the method, content type, and byte count the server received.
$ sed -n '1,12p' post-response.json { "method": "POST", "path": "/upload/post", "content_type": "text/plain", "bytes": 25, "sha256": "c0308d1638fa6ff53d7d9d14ca8de9908080f5384d9fbbba99a613bb009bab12", "body_text": "sample payload from wget\n" }An echoed byte count or body preview is a strong confirmation that the endpoint received the same payload that was stored in the local file.
- Send the same file contents with PUT when the endpoint expects an idempotent object write.
$ wget --method=PUT \ --body-file=upload.txt \ --header='Content-Type: text/plain' \ --output-document=put-response.json \ https://api.example.net/upload/put --2026-03-27 10:13:29-- https://api.example.net/upload/put Resolving api.example.net (api.example.net)... 203.0.113.50 Connecting to api.example.net (api.example.net)|203.0.113.50|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 218 [application/json] Saving to: 'put-response.json' 0K 100% 41.6M=0s 2026-03-27 10:13:29 (41.6 MB/s) - 'put-response.json' saved [218/218]PUT commonly replaces the remote resource at that path, so the target URL should identify the exact object that is meant to be updated.
- Confirm the server returned a success status code for the write request.
$ wget --server-response --quiet \ --method=PUT \ --body-file=upload.txt \ --header='Content-Type: text/plain' \ --output-document=/dev/null \ https://api.example.net/upload/put 2>&1 | grep 'HTTP/' HTTP/1.0 200 OK
The same pattern works for binary payloads as long as the endpoint expects a raw request body and the correct Content-Type is supplied.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
