Troubleshooting

Turn on Encode images. This is the single most common problem we see, and that setting fixes nearly all of it.

The preview is drawn by your reader's own browser, which is already allowed to load your images. The PDF is built on our servers, which have to fetch those images from your site as a stranger would. If your host blocks unfamiliar visitors, or the images sit behind a login or a firewall, our request comes back empty and the image is simply absent from the PDF.

With the setting on, the images travel with the page from the reader's browser and we never ask your server for anything. It is a Pro setting, in the builder and in the plugin's settings. More detail on Actions and Pro Features.

Using the extension rather than your own site? This setting is not yours to turn on, because the site belongs to somebody else. Print instead of making a PDF and the images will be there, since printing happens in your own browser.

If they are missing from the preview as well as the PDF, this is not the problem above. Check in order:

Is Show images switched off? It is a setting, and it does exactly this.

Are the images loaded by script? Galleries, carousels and lazy-loading that only fills in src once something scrolls often leave nothing for us to find.

Are they background images in CSS? A decorative background is not part of the article, and is left out on purpose.

If it happens on one page, that page is usually very long, very heavy with images, or slow to load. Our renderer gives up rather than hanging. Try the same page with images turned off; if that works, the size was the problem.

If it happens on every page and did not before, it matters how you started. Pasting an address into the box on printfriendly.com is the one route where we fetch the page ourselves, so bot protection, a firewall rule or a members-only wall will stop it. Open the page in a private window to see what we would see.

The extension, and the Print Button on Pro, do not work that way: they read the article in the browser and send it to us, so a login is no obstacle and the cause is elsewhere. The free Print Button does fetch, because it sends your reader to printfriendly.com.

If the preview works and only the PDF fails, try Encode images first, since a blocked image fetch is the most common cause.

If the missing part lives in a tab, an accordion, a “read more” section or anything else closed when the page loads, turn on Show hidden content. Read the caution on Actions and Pro Features first: it keeps everything the page was hiding, menus and cookie banners included.

If the article simply stops partway with nothing hidden, we picked the wrong block of the page as the article. Send us the URL. We hold content rules per site, and that is something we fix on our side rather than something you configure.

This is your own host's bot protection refusing us, not something on our side. Several hosts, SiteGround among them, show a page titled “Robot Challenge Screen” to visitors they do not recognize, and our servers are exactly that: an unfamiliar visitor arriving from a data center.

It bites whenever we fetch something from your site rather than receiving it from your reader's browser: your images on any plan, and on the free Print Button the whole page, because free sends your reader to printfriendly.com for us to build the preview there.

Two ways out. Turn on Encode images, which sends the images from the reader's browser so we never ask your server at all. Or ask your host to allow our servers, in which case write to us and we will send you the addresses to give them.

Send us the URL. Which parts of a page count as the article is decided by rules we hold per site, so a table being treated as layout rather than content is something we correct centrally, and the fix then applies to every page on your site at once.

If you would rather not wait, you can point us at the right elements yourself with the selectors on the settings reference.

Send us a URL. WebP is widely supported and should work, so this is worth us looking at rather than you working around.

If you need a fix today, serving a JPEG or PNG fallback alongside the WebP will get the images into the output.

Your site stripped the script out of the code you pasted. This is covered in full, with how to confirm it, on adding the code.

Something changed on one of three sides. On yours: a theme or plugin update, a new caching layer, new bot protection, or a move to a new host. On your reader's: a browser update or a new extension. On ours: rare, but possible.

The quickest way to tell them apart is to try a page from a different network and a different browser. If it works there, the problem is local to the reader. If it fails everywhere and started without you changing anything, send us the URL and roughly when it started.