A WordPress PDF that will not open can have two different failures: the document cannot be fetched, or the page's embedded viewer cannot display a valid document. Open the direct file link first. A blank viewer alone does not prove that the PDF is missing.
Copy the document URL, not the page URL
Open the File block or Media Library entry and copy the file URL. Some links lead to an attachment page instead of the document itself. Test the direct URL in a signed-out browser using a public, non-sensitive file.
If this is a private document, do not make it public to troubleshoot. Use an authorized account and a synthetic replacement file. Avoid pasting signed download URLs into public support tools because the query string may grant access.
Read what the server actually returns
In browser developer tools, keep Network open while clicking the link. Record the final URL, response status, Content-Type, and Content-Disposition. Follow the request through any redirects.
| Result |
Likely next investigation |
| 404 |
Wrong path, missing object, or case mismatch |
| 403 |
Access policy, expired signed URL, or firewall |
| 200 with HTML |
Login page, challenge, or application fallback |
| PDF downloads but viewer is blank |
Embed behavior or browser support |
A command-line header check for your own public file is:
curl -sS -I --max-time 20 'https://example.com/wp-content/uploads/guide.pdf'
Replace the example URL. A HEAD request is only a first check; confirm a normal browser GET too because some servers handle the two differently. Do not disable TLS verification to obtain a passing response.
Direct document: Test the actual file URL. Response body: A 200 status can still deliver HTML. Local PDF reader: Confirm pages and document revision. Embedded viewer: Keep a plain download link available. Explanatory checklist, not a customer test result.
Check the file independently
Download the file and open it in a trusted local PDF reader. Confirm its page count and visible content. A file named guide.pdf may actually contain an HTML error response or a partial upload. If a clean local original works but the downloaded copy fails, compare their sizes and re-upload through the supported media workflow.
If other restored media is missing, follow the backup media recovery checks. Do not assume recreating a Media Library record restores the document bytes.
Decide whether to embed or download
The WordPress File block supports a download link and optional inline PDF display. Keep an ordinary descriptive link available even when embedding. Mobile browsers, accessibility tools, and reader preferences can produce different viewing behavior.
Content-Disposition can ask the browser to display a file inline or treat it as an attachment. The browser may still apply user preferences. Fix that header at the file-serving layer rather than relying on a button label to change the response.
Verify the user journey
Test the page and direct link on desktop and mobile, signed out when public access is intended. Confirm the document title, revision, and file size so you do not replace a broken download with an outdated one. For sensitive documents, also confirm unauthorized access stays denied; a page password is not a file access policy.
Ask HandL WP to trace a failing download when storage, redirects, or access controls are involved.
References: WordPress File block and Content-Disposition behavior.
References reviewed October 2, 2026. Examples are explanatory; production changes require an appropriate backup and authorized access.