An Elementor button labeled Download does not force a browser to save a PDF. The generated link, the final file origin, the server's Content-Disposition header, and browser preferences all affect the result. Start by confirming that the button points to the actual document, not its attachment page.
This guide is for a valid PDF that opens successfully but behaves differently from the intended download action. If the document is missing or corrupt, use the PDF response troubleshooting guide first.
Inspect the published link
In Elementor, check the link field on the actual button or call-to-action widget. Compare it with the anchor in the published page. A global widget, dynamic field, or stale template can make the live target different from the editor preview.
Elementor documents a link custom attribute using a pipe separator, such as download|guide.pdf, in its download-link instructions. Enter this in the link's custom attributes, not in a CSS class field. Verify the resulting anchor has the intended attribute after publishing.
Compare the origins
The HTML download attribute generally works for same-origin links, along with blob and data URLs. A document on a media subdomain or storage CDN has a different origin from the page, even when both belong to the same business. The MDN anchor reference documents this restriction and browser-dependent behavior.
| Page and file |
What to check |
| Same scheme, hostname, and port |
Generated download attribute and file response |
| Different media hostname |
Server-controlled attachment delivery |
| Same-origin URL redirects to a CDN |
Final destination, not only the first link |
| Link opens an HTML page |
Wrong target rather than a download-policy problem |
Target: Actual PDF, not attachment page. Filename: Correct revision and name. Access: Private files remain private. Analytics: Click is not completed download. Explanatory checklist, not a customer test result.
Fix the delivery contract, not the label
For an authorized cross-origin file host, configure the download route to return the appropriate Content-Disposition attachment response and filename through its supported settings. Test a dedicated route or file before applying a global policy. Making every PDF an attachment can break intentional embedded viewers elsewhere.
Do not copy a confidential file into public WordPress uploads to make the link same-origin. Keep access control intact. Also avoid an improvised proxy that fetches arbitrary user-supplied URLs; that creates a separate security problem.
Define a realistic acceptance test
Use a small, non-sensitive test document. On desktop and mobile, verify the destination, document revision, filename, and whether the browser offers its normal save or open controls. Browser settings can still influence what happens after download, so do not promise an identical dialog everywhere.
Check keyboard activation and a descriptive button name such as Download product guide, PDF. If a new tab is intentional, communicate that accessibly. Test the ordinary link without custom JavaScript so a script error does not remove access to the document.
Finally, separate a download-button click from a completed download in your analytics. A click event proves intent, not that a person saved or read the file. HandL WP can inspect the Elementor link and file-response path when the editor settings appear correct but the live browser behavior differs.
References reviewed October 9, 2026. Examples are explanatory, not customer test results.