PDF skill (skill_id: pdf)

Why you'd careThe problem it solves

PDF is the default "send this to a human" format — the invoice, the report, the signed thing. Producing one from an LLM normally means you writing a reportlab layout or wiring up a headless browser, neither of which is the work you wanted to be doing. So the existence of a pdf skill reads like a clean answer. Then you go to use it and find the descriptions do not line up: one source says it generates formatted documents and reports, another describes a skill that extracts text and fills form fields. Those are different capabilities, and building on the wrong one wastes a sprint. Worse, for the reading half of the problem there is a good chance you do not need a skill at all — the API can already take a PDF as input directly.

ConceptWhat it is

The PDF skill is an Anthropic-authored skill for producing formatted PDF documents, referenced as {"type": "anthropic", "skill_id": "pdf"} in container.skills with the code-execution tool enabled. Like the other document skills it is a directory of instructions plus bundled scripts on the container filesystem, and its output leaves via the Files API.

The boundary that matters most is not against other skills — it is against the API's native PDF input. Sending a PDF to Claude requires no skill and no container: you attach a document content block, either base64 or a Files API reference, optionally turn on citations, and get page-anchored answers back. That path is separate, older, more widely available, and cheaper. The skill is about the other direction.

Which brings us to the ambiguity this page exists to name. Anthropic's docs describe the hosted pdf skill in one line as generating formatted PDF documents and reports. The anthropics/skills repository publishes a pdf skill whose described scope is broader — extraction and form-field handling as well. The repo characterises the document skills as source-available. So there are plausibly two artefacts sharing a name: what the hosted skill_id mounts, and what you get if you vendor the repo version yourself. Treat the hosted one as generation until you have confirmed otherwise on your own account.

How it worksThe mechanics

The wiring is identical to the other pre-built document skills: declare the skill in container.skills and declare the code-execution tool. No beta header is required, including on the Files API calls that upload inputs or download outputs. Claude loads only the skill's name and description until your request matches it, then reads SKILL.md and runs the bundled scripts in the sandbox. The generated PDF is written to the container filesystem and retrieved by file ID.

For the reading direction, the shape is completely different and worth having side by side:

{"role": "user", "content": [
  {"type": "document",
   "source": {"type": "file", "file_id": "file_..."},
   "citations": {"enabled": true}},
  {"type": "text", "text": "Which clause covers termination for convenience?"}
]}

No container, no skill, no code execution. With citations enabled the response splits into text blocks carrying a citations array, and PDF citations use page_location with 1-indexed start_page_number and end_page_number — so you can point a reviewer at page 14 rather than asserting a fact.

How to settle the generation-versus-extraction question on your own account, rather than taking anyone's word: send one request declaring skill_id: "pdf" and ask for something that is unambiguously extraction — enumerate the form fields in an uploaded PDF and report their names. Read what actually runs in the tool-result blocks. If the skill's own scripts handle it, the broader scope is live on your surface; if Claude falls back to writing generic pypdf or pdfplumber code, you have the generation-only skill plus a general-purpose sandbox, which is a materially different thing to build on.

At a glanceSee it

Reading a PDF needs no skill; making one does — and the extraction claim is unsettled.

Where it runsSurfaces and availability

The Bedrock and Vertex rows are the useful ones, and they survive checking exactly as written: in Anthropic's own feature matrix, PDF support is generally available on both platforms while Agent Skills and code execution are listed on neither. Both platforms can read a PDF and neither can write one through a skill, which means a team building document workflows there will get halfway and stall. Split your requirements along that line early: consumption is portable across every surface; production follows Anthropic's container and nothing else. Checked against primary sources 2026-07-25.

ExampleIn the real world

A compliance team produces a monthly vendor-risk report that goes to an external auditor as PDF. The request declares skill_id: "pdf" and the code-execution tool, and uploads two inputs: last month's report for house style, and findings_july.json from the internal scanner.

Claude reads the skill after the request matches, then writes a script that loads the JSON, groups findings by severity, and lays out a document: a cover page with the reporting period, an executive summary, a severity table, and one page per critical finding with the remediation owner and due date. It runs the script, sees that a long vendor name overflows the table column, adjusts the column widths, and re-runs.

The response is two sentences and a file ID. The application downloads vendor-risk-2026-07.pdf with the Files API and attaches it to the auditor's portal submission.

What the team deliberately did not do is use the same skill to read last quarter's auditor response letter. That PDF goes in as a document content block with citations enabled, so the answer comes back pointing at page 6 — no container, no beta header, and — sent as base64, since Bedrock has no Files API — it works on the Bedrock deployment their EU workloads run on.

Not thisWhat it is often confused with

• Not the PDF input pathattaching a PDF to a message uses a document content block and needs no skill, no container and no code execution. Confusing the two is the single most common waste of effort here.
• Not an OCR servicewhatever the skill's extraction scope turns out to be, a scanned image of a page is a vision problem. Send it as an image and let the model read it, or run OCR before the model sees it.
• Not guaranteed to be the repo skillthe source-available pdf skill in anthropics/skills and whatever the hosted skill_id: "pdf" mounts may differ in scope. Do not port a repo capability into a hosted design without testing it.
• Not a print pipelineno fonts you install, no colour profiles, no bleed. If the output goes to a press rather than a screen, this is not the tool.
• Not a signature workflowproducing a PDF and getting it legally signed are unrelated problems, and the second one lives entirely in your e-signature vendor.

LimitsWhen not to reach for it

• You want to ask questions about a PDF.Use a document content block with citations. It is cheaper, faster, works on more platforms, and gives you page-anchored answers.
• The layout is fixed and legally sensitive.Generative layout drifts. Use a real template engine and let Claude produce the field values that go into it.
• You need extraction and cannot test first.Given the documented ambiguity in scope, do not design an extraction pipeline around this skill until you have watched it run on your account.
• The document must be produced inside your network.The skill's container is Anthropic's. If the source data cannot be uploaded, the skill cannot see it.
• You already have a rendering service.If your stack has a working HTML-to-PDF path, having Claude write the HTML and reusing your renderer keeps the output deterministic and the diff reviewable.

RelatedGo deeper