application/pdf PDF Flagship

What it's for

application/pdf identifies files in Adobe's Portable Document Format — the standard for fixed-layout documents meant to look identical regardless of device, OS, or software used to view them. It's the default choice for invoices, contracts, reports, forms, and anything where exact visual layout matters more than easy editability, which is precisely the opposite design goal of formats like HTML or plain text.

Browsers have built-in PDF viewers today, so serving application/pdf with the right disposition (see below) lets you choose between showing a PDF directly in the browser tab or prompting a download, without needing any client-side plugin the way this used to require in the pre-native-viewer era.

Format & syntax

Content-Type: application/pdf
Content-Disposition: inline
Content-Disposition: attachment; filename="invoice.pdf"

The MIME type alone doesn't control download-vs-view behavior — that's the job of the Content-Disposition header alongside it. inline tells the browser to display the PDF directly (using its built-in viewer); attachment (with a suggested filename) triggers a download prompt instead. This pairing is a very common point of confusion since people expect the MIME type alone to control this behavior.

How it's used in practice

• Downloadable reports, invoices, and receipts — generated server-side (via libraries like wkhtmltopdf, Puppeteer/Browsershot, or dedicated PDF libraries) and served with application/pdf, often as an attachment for a clean "Save As" experience.
• Inline document preview — embedding a PDF directly in a page (via an <iframe>, <embed>, or a link opened in a new tab) relies on Content-Disposition: inline so the browser's native viewer renders it in place rather than downloading it.
• Form submission and document upload validation — file upload endpoints commonly validate the incoming file's MIME type against application/pdf (ideally by inspecting actual file content/magic bytes, not just trusting the client-supplied Content-Type, which can be spoofed) before accepting a document upload.
• Print-friendly exports — many "export this page/report as PDF" features in web apps generate a PDF server-side specifically because it guarantees consistent print layout across different browsers and devices in a way that browser print-to-PDF from arbitrary HTML doesn't always achieve reliably.

Common mistakes & gotchas

• Trusting the client-supplied Content-Type on upload without verification — a malicious upload can claim Content-Type: application/pdf while actually containing something else entirely. Server-side validation should check the file's actual magic bytes (PDF files start with %PDF-) rather than trusting the header alone, especially for security-sensitive upload flows.
• Forgetting Content-Disposition and getting unexpected download/view behavior — serving a PDF with only Content-Type: application/pdf and no explicit Content-Disposition leaves the browser's default behavior in charge, which can vary; being explicit about inline vs attachment avoids surprises.
• Not setting a sensible filename in Content-Disposition — when using attachment, omitting the filename parameter means the browser falls back to a generic or URL-derived filename, which is often a poor user experience compared to a deliberately chosen one (invoice-2026-08.pdf rather than download.pdf or a hashed filename).
• Large PDF generation timing out — server-side PDF generation (especially HTML-to-PDF rendering) can be slow for complex documents; not handling this asynchronously (queue-based generation with polling or webhook notification) is a common scaling issue once PDF generation moves beyond simple, small documents.

Comparison & FAQ

How do I make a PDF open in the browser instead of downloading?

Set Content-Disposition: inline alongside Content-Type: application/pdf. Without an explicit disposition, browser behavior can vary; being explicit is the reliable approach.

Is it safe to trust the Content-Type header when validating a PDF upload?

Not on its own — a client can send any Content-Type value regardless of actual file content. For real validation, check the file's magic bytes (%PDF- at the start) or use a proper file-type detection library server-side.

Why does my downloaded PDF have a weird filename?

You likely didn't set the filename parameter in the Content-Disposition: attachment header — without it, the browser falls back to a generic name or one derived from the URL, rather than a name you deliberately chose.

What's the difference between generating a PDF server-side vs. using the browser's print-to-PDF feature?

Server-side generation gives you consistent, controlled output regardless of the viewing device or browser, while browser print-to-PDF depends on the browser's own print rendering, which can vary in layout fidelity across different browsers and print stylesheets.