PDF Not Loading
Fix a PDF that won't display in Custom iFrame for Elementor and Gutenberg. Covers server headers, Google Drive preview URLs, authentication, and mixed content.
Overview
A PDF that fails to load inside an iFrame is usually caused by one of four things: the server forces the file to download instead of display, the URL points to a viewer page rather than the file itself, the file requires authentication, or there is an HTTP/HTTPS mismatch. This guide covers each cause with a specific fix.
Cause 1: The Server Forces a File Download
Some servers send a Content-Disposition: attachment HTTP response header when serving a PDF. This tells the browser to download the file instead of rendering it inline. The iFrame displays blank because the browser receives a file download, not a displayable page.
How to identify this: Open the PDF URL directly in a browser tab. If the browser immediately downloads the file instead of opening it, the server is sending this header.
Fix: You need a URL that serves the PDF with inline display headers. Options:
- Host the PDF on your own WordPress site (Media Library). WordPress serves PDFs inline by default.
- Use a Google Drive preview URL (see Cause 2 below).
- Use a PDF hosting service that serves files inline, such as PDFhost.io or a CDN configured for inline delivery.
Cause 2: The URL Is a Viewer Page, Not a Direct PDF Link
Google Drive
Google Drive file URLs come in two formats. The wrong format loads the Drive viewer interface, which blocks embedding.
| URL format | Result |
|---|---|
drive.google.com/file/d/FILE_ID/view | Loads Drive viewer — blocks iFrame |
drive.google.com/file/d/FILE_ID/preview | Designed for iFrame embedding |
Fix: Change /view to /preview in the Google Drive URL.
Before: https://drive.google.com/file/d/ABC123/view?usp=sharing
After: https://drive.google.com/file/d/ABC123/preview
Also confirm the file sharing is set to Anyone with the link can view. A private or restricted file shows a login prompt inside the iFrame.
Dropbox
Dropbox sharing links point to a Dropbox page, not the file itself. Direct download links force a download rather than inline display.
Fix: Replace www.dropbox.com with dl.dropboxusercontent.com in the URL and remove any ?dl=1 parameter. This serves the raw PDF directly, which browsers can render inline.
Cause 3: The PDF Requires Authentication
If the PDF is stored in a private location (Google Drive private file, password-protected page, paywall, or corporate intranet), the iFrame loads a login prompt or error page instead of the PDF.
Fix: Make the PDF publicly accessible. There is no way to pass credentials through Custom iFrame to authenticate against a protected document.
Cause 4: Mixed Content (HTTP PDF on an HTTPS Site)
If your WordPress site runs on HTTPS and the PDF URL starts with http://, the browser blocks the request as mixed content. The iFrame remains blank with no visible error on the page.
Console error: Mixed Content: The page at 'https://yoursite.com' was loaded over HTTPS, but requested an insecure frame 'http://...'
Fix: Use an https:// URL for the PDF. If the hosting server does not support HTTPS, the PDF cannot be embedded on an HTTPS WordPress site.
Cause 5: Height Is Too Small to Display the PDF
A PDF loaded successfully but appearing as a thin blank strip is a height issue. The iFrame is too short to show any PDF content.
Fix: Set the height to at least 600px. For full-page documents, 800–900px works better. See the iFrame Height Fix guide for a full reference table.
Cause 6: 3D Flipbook View Is Not Displaying
The 3D Flipbook View is a Pro feature that renders PDFs in a page-turning interface.
If the flipbook is blank or shows incorrectly:
- Set height to at least 500px. For A4 documents, 600–800px is recommended.
- Turn Auto Height off. Auto Height conflicts with the flipbook layout and must be disabled.
- Confirm the source is a direct PDF URL or uploaded PDF file. The flipbook cannot render a Google Drive viewer URL.