Generate HTML for displaying a publicly hosted PDF with an iframe or object element, or create a link users can open or download.
Last updated: August 2026 | By Workshelve Team
The file must already be hosted at a URL your visitors can access. This tool does not upload or host the PDF.
This tool does not put the PDF file inside your HTML document. It creates markup that points to a PDF that is already available at a web URL. When a visitor opens the page, their browser requests that URL separately.
An iframe creates a nested browsing context. An object element can ask the browser to treat the remote resource asapplication/pdf and can contain fallback content for cases where the resource is not displayed.
Browser PDF support is not identical everywhere, so a normal link to the PDF remains useful even when you also provide an inline viewer.
The HTML can be valid and the PDF can still fail to appear inline. The server hosting the resource can send security policies that restrict where its content may be framed, and your own site's Content Security Policy can restrict which sources its iframes are allowed to load.
The URL also needs to be accessible to your visitors. A private cloud-storage link that only works while you are signed in is not automatically a public PDF embed URL.
A straightforward inline frame. It is a good first option when the PDF URL can be displayed by the visitor's browser.
Declares the resource as application/pdf and includes fallback link content inside the element.
The most predictable fallback. A normal link lets the browser decide whether to open, display, or download the PDF.
WordPress.com supports raw iframe code through its Custom HTML block on plans where that code is allowed. Wix provides Embed HTML or Embed Code elements for custom snippets. Squarespace supports embed/code blocks, although iframe availability can depend on the site plan.
Platform interfaces and plan restrictions can change, so the platform mode deliberately generates ordinary HTML rather than pretending there is a special proprietary PDF API for each builder.
No. It generates HTML from a URL you provide. You must host the PDF somewhere your site visitors can access.
For cross-origin URLs, the HTML download attribute may be ignored. Browser settings and the PDF server's response headers can also affect whether a PDF opens or downloads.
No guarantee. The remote host or your site's security policy can restrict embedding, and the visitor's browser still decides how it handles the PDF resource.
Not necessarily. A URL can serve a PDF without a .pdf filename. What matters to the browser is the resource it receives and the server response, not only the visible URL suffix.
Use a short description of the embedded document, such as "2026 annual report," rather than a generic label when possible.
A percentage width makes the embed adapt to its container, while a fixed pixel height gives the inline viewer a predictable vertical area. You can edit the generated HTML afterward if your layout needs different CSS.
It provides fallback HTML inside the object element, but PDF handling still varies. A separate visible link elsewhere on the page is the safest additional fallback.
The URL and title are HTML-escaped before insertion, but you should still review generated code and only embed URLs you trust and intend to expose to visitors.
Related Tools
Convert BMP images to PDF.
Convert WEBP images to PDF.
Fix crooked scanned pages.
Trim margins or whitespace from pages.
Apply legal Bates numbering.
Remove comments and markups.