An agent finishes a task and holds a PDF: a report, an invoice, a summary a human asked for. Now it needs to put that file somewhere a person or another system can fetch it. The options differ more than they first appear.

Option 1: a pastebin

Pastebins are built for text. A PDF is binary, so the agent must base64 it, the consumer must decode it, and the paste site's size limits arrive fast. Retention is whatever the free tier feels like, there is rarely a stable API contract, and CAPTCHAs or rate walls appear exactly when automation shows up.

Verdict: fine for a code snippet, wrong shape for a file. If the artifact is genuinely plain text — a log, a diff — a pastebin can work, but you still inherit its retention and automation limits.

Option 2: S3 with presigned URLs

The serious infrastructure answer. S3 is durable and cheap, and presigned URLs give out time-limited access without making the bucket public.

The costs are operational. The agent needs AWS credentials with IAM policies scoped correctly — a real setup and rotation burden, and a real blast radius when a key leaks. Presigned GET URLs expire (commonly capped around a week depending on the signing method), so every link you hand a customer has a countdown attached, and "the report link stopped working" becomes a support category. Making objects permanently public instead means owning bucket policy correctness, which is a famous source of accidents.

Verdict: right when you already run AWS infrastructure and want private delivery. Heavy when the actual requirement is "give this file one public URL that keeps working".

Option 3: a data URI

Encode the PDF as data:application/pdf;base64,… and paste it inline. No host at all — which is the whole problem. Base64 inflates size by a third, chat platforms and ticket systems truncate or strip long URIs, browsers cap their length, and nothing about it is a link you can fetch later. It also jams megabytes of noise into any transcript or context window that carries it.

Verdict: a last resort for tiny files inside a single HTML page you control. Not delivery.

Option 4: a durable public URL

DurableFile is built for exactly this handoff:

curl -X POST https://durablefile.com/v1/upload \
  -H "Authorization: Bearer $DURABLEFILE_KEY" \
  -F "file=@quarterly-report.pdf"

{
  "status": "live",
  "public_url": "https://f.durablefile.com/f/…/quarterly-report.pdf"
}

The properties that matter for an agent:

  • No signup wall. One POST creates the account; no email, CAPTCHA, or dashboard. See the account model.
  • No link countdown by default. A link with no expiry has no automatic expiry — and when you want a temporary link, the expiry is explicit and reversible.
  • Idempotent uploads. Same bytes, same URL, retries free.
  • Known pricing. $1 per 1 GiB, one-time, stacks. No subscription to babysit.
  • Download-only delivery. Files serve as attachments; nothing executes in a browser.

The honest limits, stated plainly: files are public — anyone with the URL can download them, so confidential documents do not belong here. Only PDF, plain text, Markdown, CSV, and JSON are accepted, at up to 25 MiB. And storage costs real money up front, because payment is the abuse gate that replaces signup friction.

What about images?

Same decision, different product. Direct image uploads are rejected here with a machine-readable pointer to imgd.dev — the sibling host built for images, with the same no-email account model.

The short version

Need Use
Private delivery inside existing AWS infra S3 presigned URLs
A code snippet, not a file A pastebin
A public, stable, shareable file URL DurableFile
An image imgd.dev
Almost never A data URI

If the deliverable is public and needs to outlive the conversation that produced it, a durable content-addressed URL is the default that fits.