Blog

Reading PDFs in Safari with Claude (no clicking, no downloading)

By Alwaz T. May 24, 2026

PDFs are everywhere in research: white papers, industry reports, supplier catalogues, legal documents, academic papers. When you land on one in Safari and you want Claude to read it, the obvious approach is to download it and attach it to a Claude conversation. That works. It is also slower than it needs to be. There is a cleaner approach using curl directly against the PDF URL, and it removes several steps from the workflow.

The standard download-and-attach workflow

The default approach most people use:

  1. Click the PDF link in Safari
  2. Safari downloads it to ~/Downloads
  3. Open Claude Desktop
  4. Drag the PDF into the conversation
  5. Wait for Claude to process it
  6. Delete the PDF from ~/Downloads when done

Six steps. Maybe two minutes including file management. Works, but is annoying for high-volume research.

The curl-based workflow

The faster approach:

  1. Right-click the PDF link in Safari and copy the URL
  2. In Claude, ask Claude to fetch and read the PDF from that URL

Two steps. Claude runs curl -L -o /tmp/document.pdf "URL" behind the scenes, then reads the PDF directly from disk. No download to ~/Downloads, no cleanup, no file management.

The exact command Claude runs

Behind the scenes, the workflow Claude executes:

curl -L -o /tmp/doc-$(date +%s).pdf "https://example.com/report.pdf"

The -L follows redirects (PDFs are often served from CDNs after a redirect). The -o specifies the output file. Using $(date +%s) in the filename ensures uniqueness so concurrent downloads do not overwrite each other.

Once the PDF is downloaded to /tmp, Claude reads it the same way it would read any PDF attached to a conversation. Tables, structured text, and most images render correctly.

When curl works and when it does not

Curl works for

Curl does not work for

For the last category, you may need to download via Safari first (so the browser handles auth and cookies) and then attach the file to Claude the traditional way.

Reading multiple PDFs at once

For research workflows where you have 5 to 20 PDFs to read, curl scales much better than download-and-attach. You can give Claude a list of URLs and have it fetch all of them in parallel:

# In the terminal
for url in $(cat pdf-urls.txt); do
  curl -L -o "/tmp/$(basename $url)" "$url" &
done
wait

This downloads all PDFs concurrently. Claude then reads them sequentially or in groups. For something like an industry-report bulk review (read 15 white papers in your category), this is the difference between 30 minutes of manual download-and-attach and 5 minutes of fully automated processing.

Real example: reading a Shopify industry report

Suppose you want Claude to read the most recent Shopify Plus state-of-commerce report. The URL is publicly available. Standard workflow:

  1. In Safari, navigate to the report landing page
  2. Right-click the download link, copy URL
  3. In Claude: "Curl this PDF and summarise the key findings for a DTC brand at $5m annual revenue: [URL]"

Claude curls the PDF to /tmp, reads it, and produces a 500 to 800 word summary calibrated to your specific brand stage. Total time: 30 to 60 seconds depending on PDF size.

Compare to the manual approach: click the link, wait for download, find the file in Downloads, drag into Claude, wait for processing, then prompt. Maybe 3 to 4 minutes including file management.

Cleaning up /tmp

macOS clears /tmp on every reboot, so PDFs Claude downloads there are temporary by design. For users who reboot less frequently, you can clear them manually:

rm /tmp/*.pdf

Or set up a launchd job to clear /tmp/*.pdf weekly. Either approach keeps your /tmp clean.

Combining with Safari for the URL

When you find a PDF link in Safari, the fastest workflow is:

  1. Right-click the link, "Copy Link"
  2. In Claude: "Curl and read this PDF: [paste URL]"

The two clicks (right-click and Copy Link) are the only interaction with Safari. Claude does the rest from the terminal.

Privacy and storage considerations

PDFs you curl to /tmp persist on your local disk until /tmp is cleared. For sensitive content (legal documents, confidential reports), be aware they live on disk during the session even though /tmp is cleared on reboot. For highly sensitive content, ask Claude to delete the file immediately after reading:

# Claude can do this as part of the workflow
rm /tmp/sensitive-document.pdf

Why this workflow scales

The reason this matters is high-volume research. Anyone doing manual download-and-attach beyond five PDFs per session is wasting time. The curl-based approach scales linearly with how many PDFs you have to read; the manual approach scales painfully with how many clicks and drag-and-drops you can tolerate.

For ecommerce founders doing supplier research, regulatory compliance reading, or industry report analysis, this is the workflow worth learning once and using forever.

Bottom line

Curl works for the vast majority of public PDFs you encounter in Safari. It removes several steps from the read-a-PDF-with-Claude workflow and scales to high-volume research without friction. For authenticated or session-gated PDFs, fall back to the manual download-and-attach approach.

At ScaleWise VA we use the curl workflow for industry-report reading and supplier catalogue analysis. If you want help building this kind of efficient research workflow into your Shopify operations, book a free 30-minute call.

How this PDF workflow shows up in Shopify operations

The curl-based PDF reading workflow is a daily tool in Shopify operations work. Specific cases where it earns its keep:

The PDF workflow is the kind of small operational efficiency that compounds across a year of customer support and ops work. Each instance saves 10-15 minutes. Across a year, that's 30-50 hours of recovered time per VA.

If you want this kind of operational efficiency built into your team's daily workflow, book a discovery call.

Work With Us

Want to work with us?

Book a free 30-minute discovery call. We'll review your store and tell you exactly what we'd do.