Saving cURL output to local files makes API responses, rendered pages, and downloaded artifacts reusable after the terminal scrollback is gone. Stored results can be inspected later, handed to another command, compared between runs, or archived with other troubleshooting data.
By default, cURL writes response data to standard output, so file capture depends on whether the goal is the response body, a server-provided filename, or the diagnostic stream. --output writes the body to an explicit path, --remote-name keeps the filename from the URL, and --stderr sends transfer errors to a separate log instead of mixing them with the saved body. The examples below use masked export and status endpoints so the save patterns stay realistic without publishing a live service.
Overwriting an existing file happens silently unless the workflow checks for it first, appending can create hard-to-read mixed captures, and failed transfers can leave misleading partial downloads. Use dedicated filenames, append only when building a deliberate log, and add --remove-on-error when a failed request should not leave behind stale output.
Steps to save cURL output to a file:
- Create a dedicated workspace for saved response files and logs.
$ mkdir -p ~/curl-save-output $ cd ~/curl-save-output
Keeping captures in one directory makes it easier to inspect, compare, and remove them after the request flow is finished.
- Save the response body to an explicit filename with --output.
$ curl --silent --output ops-health-summary-current.json https://downloads.example.net/exports/2026-03/ops-health-summary-2026-03-29.json $ wc -c ops-health-summary-current.json 512 ops-health-summary-current.json--output writes only the response body to ops-health-summary-current.json, while diagnostics still go to standard error unless redirected separately.
- Inspect the saved file to confirm that the expected content was written.
$ sed -n '1,6p' ops-health-summary-current.json { "report_id": "ops-health-2026-03-29T1400Z", "generated_at": "2026-03-29T14:00:00Z", "region": "ap-southeast-1", "status": "ok", "checks": [Reading a few lines back immediately catches cases where the saved output is an error page, redirect target, or unexpected content type.
- Append later responses with >> only when building a rolling capture file on purpose.
$ curl --silent https://status.example.net/probes/edge-ap-01/summary.txt >> transfer-history.log $ curl --silent https://status.example.net/probes/edge-ap-02/summary.txt >> transfer-history.log $ wc -l transfer-history.log 2 transfer-history.logAppending is useful for request transcripts and repeated samples, but it is a poor fit for files that must stay valid JSON, HTML, or binary data.
- Save transfer errors to a separate log and remove failed output files in the same run.
$ curl --fail --silent --show-error --remove-on-error --output missing-export.html --stderr curl-error.log https://downloads.example.net/exports/2026-03/missing-export.html $ test ! -e missing-export.html && echo "missing-export.html not created" missing-export.html not created $ cat curl-error.log curl: (56) The requested URL returned error: 404
--fail turns HTTP error responses into curl failures, --stderr keeps the error text out of the saved body path, and --remove-on-error prevents a broken partial file from being reused later. Depending on the HTTP version or server behavior, the published curl error code can appear as 22 or 56, but the failed transfer should not leave missing-export.html behind.
Related: How to fail on HTTP errors with cURL
- Save with the remote filename when the URL already exposes the correct local name.
$ curl --silent --remote-name https://downloads.example.net/exports/2026-03/ops-readiness-summary-2026-03-29.txt $ wc -c ops-readiness-summary-2026-03-29.txt 188 ops-readiness-summary-2026-03-29.txt--remote-name uses the last path segment from the URL, so choose a clean download directory before running it against multiple files.
- Check the saved artifacts before using them in another tool or script.
$ file ops-health-summary-current.json transfer-history.log ops-readiness-summary-2026-03-29.txt curl-error.log ops-health-summary-current.json: JSON text data transfer-history.log: ASCII text ops-readiness-summary-2026-03-29.txt: ASCII text curl-error.log: ASCII text
Binary downloads, HTML error pages, and JSON payloads can all arrive through the same command, so confirm the file type before parsing, uploading, or committing the saved output elsewhere.
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.
