How to Embed a PDF in HTML: iframe vs object vs embed

By the end of this page, you will understand the main HTML options for displaying a PDF in a web page, how iframe, object, and embed differ, when each is useful, and why a fallback link is important. You will also see practical examples for dynamically generated PDFs and learn what developers usually do in real projects.

Displaying a PDF in a web page is really about embedding external content in HTML. The browser may render the PDF itself, use a built-in viewer, rely on a plugin-like PDF handler, or fail to show it at all depending on browser support and user settings.

The three HTML elements most commonly used are:

• iframe — embeds another document inside the page
• object — embeds an external resource and can include fallback HTML content
• embed — a simple embedded external resource element

Why this matters

In real applications, PDFs are often used for:

• invoices
• reports
• receipts
• contracts
• exported dashboards
• downloadable documents generated on demand

A good solution should:

• work in modern browsers as often as possible
• degrade gracefully when inline viewing is unavailable
• support dynamically generated PDFs
• avoid depending on third-party upload workflows when files are created on the fly

Practical recommendation

There is no single perfect HTML tag that guarantees PDF display everywhere. In practice:

• Use object when you want a built-in fallback message or download link inside the markup.
• Use iframe when you simply want to show the PDF viewer as a separate embedded document.
• Use a direct download link as a fallback in all cases.

The key idea is: PDF embedding depends on browser capability, not just HTML syntax.

If the PDF is generated dynamically, that is fine. You can still return it from your server with the correct headers and point your HTML element to that URL.

Think of a PDF like a document you want to place inside a picture frame on a wall.

• iframe is like hanging a second mini-window inside your page.
• object is like placing an item in a frame, but keeping a note underneath in case the item cannot be displayed.
• embed is like a very direct “put this file here” instruction.

The important part is that the wall is the browser. If the wall supports hanging that kind of frame, the PDF appears. If not, you need a backup plan, usually a download link.

Basic syntax

Using iframe

<iframe src="/files/report.pdf" width="100%" height="600"></iframe>

This loads the PDF as a nested document inside the page.

Using object

<object data="/files/report.pdf" type="application/pdf" width="100%" height="600">
  <p>Your browser could not display the PDF. <a href="/files/report.pdf">Download it here</a>.</p>
</object>

This is often a strong choice because it includes fallback content.

Using embed

<embed src="/files/report.pdf" type="application/pdf" width="100%" height="600">

This is short and direct, but it does not provide as nice a built-in fallback pattern as object.

Example with a dynamically generated PDF

If your server generates the PDF at a route like /invoice/123/pdf, you can embed that URL directly:

<object data="/invoice/123/pdf" type="application/pdf" width="100%" height="700">
  <p>
    Unable to display the invoice inline.
    <a href="/invoice/123/pdf">Download the PDF</a> instead.
  </p>
</object>

Why the fallback matters

Even if your markup is correct:

• some browsers may block inline PDF viewing
• users may disable PDF viewers
• mobile behavior may differ
• enterprise environments may restrict embedded documents

That is why many developers prefer object plus a normal link.

Example

<object data="/reports/daily.pdf" type="application/pdf" width="100%" height="500">
  <p>Preview unavailable. <a href="/reports/daily.pdf">Download the PDF</a>.</p>
</object>

What happens step by step

1. The browser reads the <object> element.
2. It sees data="/reports/daily.pdf" and requests that URL from the server.
3. The server responds with PDF content, ideally with a header like:

Content-Type: application/pdf

1. The browser checks whether it can render PDFs inline.
2. If it can, the PDF viewer appears inside the area defined by width and height.
3. If it cannot, the browser shows the fallback HTML inside <object>:

<p>Preview unavailable. <a href="/reports/daily.pdf">Download the PDF</a>.</p>

Server-side note

For dynamically generated PDFs, the server usually:

• creates the PDF content
• sends the correct Content-Type
• optionally controls inline viewing with Content-Disposition

For example:

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

Using inline suggests the browser should display the PDF in-page if possible.

Common use cases

Invoices and receipts

An app generates a PDF invoice after checkout and shows it immediately in a customer portal.

Reports and dashboards

An admin exports a monthly report as PDF and previews it before downloading.

Contracts and forms

A legal or HR system shows a generated agreement for review inside the browser.

Educational material

A learning platform displays PDF handouts or worksheets directly on a lesson page.

Internal tools

A business app embeds shipping labels, purchase orders, or audit documents in a management screen.

In all of these cases, the file may be generated on demand, so embedding a server URL is more practical than relying on a third-party viewer upload workflow.

In real projects, developers usually treat PDF embedding as a progressive enhancement rather than a guarantee.

Common patterns

1. Provide inline preview plus download

A page tries to show the PDF, but always includes a download link nearby.

<p><a href="/export/report.pdf">Download PDF</a></p>
<object data="/export/report.pdf" type="application/pdf" width="100%" height="700">
  <p>Inline preview is not available. <a href="/export/report.pdf">Download the file</a>.</p>
</object>

2. Use guard-style fallbacks

If preview is not essential, developers often avoid overengineering and simply ensure the document is accessible even when embedding fails.

3. Generate secure URLs

For private documents, the PDF route may require authentication or use a temporary signed URL.

4. Return correct headers

Teams commonly ensure:

• Content-Type: application/pdf
• Content-Disposition: inline for browser preview
• authorization checks before returning the file

5. Separate preview from download behavior

Some codebases use one route for inline viewing and another for forced download.

For example:

• /files/123/view → Content-Disposition: inline
• /files/123/download → Content-Disposition: attachment

This keeps behavior predictable.

1. Assuming one tag works everywhere

Beginners often expect iframe, object, or embed to behave identically in all browsers.

<embed src="/file.pdf">

This may work in one browser and fail or behave differently in another.

Better approach

Use a fallback link, especially with object.

2. Forgetting the correct MIME type

If the server does not send the PDF with the correct content type, the browser may not render it properly.

Problem

Content-Type: text/html

Correct

Content-Type: application/pdf

3. Forcing download when you want preview

If the server sends:

Content-Disposition: attachment

many browsers will download the file instead of displaying it inline.

Better for inline viewing

Content-Disposition: inline; filename="file.pdf"

4. Not providing a height

Without a height, the embedded area may be too small or appear broken.

<iframe src="/file.pdf"></iframe>

Better

<iframe src="/file.pdf" width="100%" height="600"></iframe>

5. Ignoring accessibility and usability

If the PDF cannot be displayed, users still need a clear way to open or download it.

Better

<object data="/file.pdf" type="application/pdf" width="100%" height="600">
  <p>This PDF cannot be displayed here. <a href="/file.pdf">Download the PDF</a>.</p>
</object>

6. Confusing embedding with conversion

Embedding a PDF does not convert it into HTML content. The browser is still showing a PDF viewer, not normal page text and layout.

iframe vs object vs embed

object vs direct link

Inline preview vs forced download

Practical takeaway

If you want a general recommendation:

• choose object when fallback content matters
• choose iframe when you want a quick embedded viewer
• always provide a download link

Quick reference

Embed with object

<object data="/file.pdf" type="application/pdf" width="100%" height="600">
  <p><a href="/file.pdf">Download the PDF</a></p>
</object>

Embed with iframe

<iframe src="/file.pdf" width="100%" height="600"></iframe>

Embed with embed

<embed src="/file.pdf" type="application/pdf" width="100%" height="600">

Recommended headers for server response

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

Good practices

• Prefer object if you want fallback HTML.
• Add a normal download link.
• Set explicit width and height.
• Test in target browsers.
• Use attachment only when you want a forced download.

Important edge case

Correct HTML does not guarantee inline PDF support. Browser capabilities and settings still control the final behavior.

Is object better than iframe for PDFs?

Often yes, because object lets you include fallback HTML content such as a download link. But both are commonly used.

Should I use embed for PDF files?

You can, but it is usually less flexible than object, especially when you want graceful fallback content.

Why does my PDF download instead of showing in the page?

Your server may be sending Content-Disposition: attachment, or the browser may not support inline PDF viewing.

Can I embed a dynamically generated PDF?

Yes. Point iframe, object, or embed to a server route that generates and returns the PDF with Content-Type: application/pdf.

Do I need Adobe Reader to display PDFs in HTML?

Usually not in modern browsers, because many have built-in PDF viewers. Behavior still varies by browser and environment.

What is the safest fallback if embedding fails?

A direct link to open or download the PDF.

Can I style the inside of the PDF viewer with CSS?

Not in the same way as normal HTML content. You can style the container element, but not the internal PDF document rendering like regular page markup.

• HTTP Content-Type — important because browsers use MIME type information to decide how to handle the response.
• Content-Disposition header — controls whether the PDF is displayed inline or downloaded.
• iframe element — closely related because it embeds another document inside a page.
• object element — central to embedding external resources with fallback content.
• embed element — another HTML option for embedded external content.
• File downloads in web apps — related because PDFs are often either previewed inline or downloaded.
• Browser compatibility — important because PDF rendering support differs across browsers and devices.
• Progressive enhancement — useful because inline PDF preview should not be the only way to access the document.