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.
$ 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.
$ 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.
$ 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.
$ 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.
$ 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.