How to Fix Missing Images When You Export HTML to PDF

You export your HTML to a PDF or an image, and one or more pictures are simply gone. Blank space where a photo should be. The image showed up perfectly on screen, so what happened? This is one of the most confusing export problems, and the cause is a security rule that trips up almost everyone the first time.

Why images disappear from exports

When an image on your page is loaded from a different website, it is called a cross-origin image. Browsers treat these carefully. They will happily display a cross-origin image, but they block any script from reading its pixels. That distinction is the whole story.

Exporting a page to an image or a raster PDF works by reading the pixels of the rendered page. When the tool reaches a cross-origin image whose host did not grant permission, the browser refuses to let it read those pixels. Rather than break the whole export, the image is dropped, and you get a blank space. So the image looks fine on screen, because displaying is allowed, but it cannot be exported, because reading is not.

How to tell this is your problem

The signs are consistent: the image is visible in the preview, it disappears only in the exported file, and the images that vanish are the ones loaded from other websites, while images embedded in the page survive. If a good export tool warns you that some images could not be included because they were blocked, this is exactly what it means.

Fix 1: embed images directly in the file

The most reliable fix is to not load images from another site at all. Images embedded directly in the HTML as data, rather than linked from a URL, are part of the file itself, so there is no cross-origin barrier and they always export. If you control the HTML, or you are asking an AI to build it, request that images be embedded in the file rather than linked. This is the surest way to guarantee they survive.

Fix 2: host images somewhere that grants permission

If images must come from a URL, host them somewhere that sends the cross-origin permission header. Many image hosts and content delivery networks do this, which is why images from some sources export fine while others fail. The difference is entirely whether the host grants read permission. If you can choose where your images live, pick a host known to send that header.

Fix 3: use a tool that proxies remote images

Some export tools solve this for you. When they hit an image the browser will not let them read directly, they route it through a proxy that re-serves the image with the right permission header, so the picture ends up in the export anyway. This happens behind the scenes and rescues images that would otherwise be dropped. If you regularly export pages with images from mixed sources, a tool that does this saves a lot of trouble. One small note: proxied images pass through the proxy's servers on the way, so it is used as a fallback for the images that need it rather than for everything.

Fix 4: replace the stubborn image with an upload

When a single image refuses to cooperate, the quickest fix is to replace it with an uploaded copy. An uploaded image becomes part of the file, just like an embedded one, so it always exports. If your tool has a way to swap an image by uploading a file, use it on any image that keeps coming out blank. It sidesteps the cross-origin issue entirely.

Step by step to a complete export

1. Export once and note which images are missing.
2. If you control the HTML, switch those images to embedded data or a permission-granting host.
3. If you do not, use a tool that proxies remote images, or replace each missing image with an upload.
4. Export again and confirm every image is present.

The core idea to remember: browsers separate showing an image from reading it. Exports need to read, and cross-origin images block that. Keep your images inside the file or served with permission, and they will always make it into the finished PDF.

How to tell which image is the problem

When several images could be at fault, narrow it down quickly. The images that survive an export are the ones embedded in the file or served with permission, and the ones that vanish are cross-origin without it. If your tool reports how many images could not be included, that number tells you how many need attention. Otherwise, compare the export to the preview and note which specific images are blank, then check where each one is loaded from. The blank ones almost always come from a different website than the page.

Background images fail the same way

It is not only images in image tags that disappear. A background image set in CSS, the kind used for a hero section or a card, follows exactly the same rule. If it is loaded from another site without permission, it will display on screen but drop out of the export. So if a section's background is missing rather than a picture, suspect the same cross-origin cause, and apply the same fixes: embed it, host it somewhere that grants permission, proxy it, or replace it.

A note on embedded images and file size

Embedding images directly in the file is the most reliable fix, but it does make the HTML larger, because the image data now lives inside the page instead of being fetched separately. For a few images this is not an issue. For a page packed with large photos, an all-embedded file can get heavy. In practice this is a fair trade for exports that actually work, and for most designs, a flyer, an invitation, a one-pager, the size is perfectly manageable. If you are dealing with many high-resolution photos, keep them reasonably sized for the page rather than embedding enormous originals, and the file stays sensible while every image still exports.

Prevent the problem from the start

The easiest missing-image problem to solve is the one you never create. When you build or request a design that you know will be printed, plan for images that will export from the beginning. Ask for images to be embedded in the file rather than linked from around the web, or gather your images first and use ones you control. A design built this way simply never hits the cross-origin wall, and every export comes out complete on the first try.

What about icons and SVGs?

Not every graphic behaves like a photo. Icons drawn as SVG code directly inside the page are part of the document, so they export without any cross-origin issue, which is one reason inline SVG icons are so reliable in print. The trouble returns only when an icon or graphic is loaded from another site as a file. The takeaway is consistent across every kind of image: if the graphic lives inside the file, it exports; if it is fetched from elsewhere without permission, it may not. When you have the choice, keep your icons and small graphics inline, and reserve remote loading for images you know are served with the right permissions.

Frequently asked questions