IT technician fixing ServiceNow KB printing where images are missing due to proxy whitelist rules

Joe B.

Reviewed for technical accuracy

Specialities: ServiceNow Knowledge Base (KB) troubleshooting, printer-friendly view, print-to-PDF issues, missing embedded images/screenshots, sys_attachment access.

ServiceNow KB prints no images: why screenshots disappear in PDF and how to whitelist proxy/attachment domains

Technician avatar Technician
Hi! We can fix ServiceNow KB prints no images — this is usually caused by (1) the article’s images being loaded from sys_attachment URLs that your proxy/content filter blocks during print/PDF capture, or (2) an attachment permission/ACL issue where the browser can display the text but can’t fetch the image file when printing.

Quick questions so we pinpoint the exact root cause (proxy vs permissions vs page type):
• Where are you printing from: Platform UI “View Article” / kb_view.do, Service Portal / Employee Center (e.g., sp?id=kb_article), or a custom KB page?
• Are images missing only in the print preview / PDF, or are they also missing on-screen (broken image icon / alt text)?
• What do the image URLs look like when you right-click an image and “Open image in new tab”? Common ones are sys_attachment.do?sys_id=… or /api endpoints.
• Are you behind a corporate proxy like Zscaler / Blue Coat / FortiGate, or any SSL inspection / web filtering?
• Which browser are you printing from (Chrome/Edge), and are you using “Print friendly version” or straight Ctrl/Cmd+P?

Answer those and I’ll give you a step-by-step diagnostic plus the cleanest proxy whitelist / allowlist for ServiceNow KB images.
Customer
We’re in ServiceNow Knowledge. On-screen the article shows images fine most of the time, but when we print to PDF (Chrome) the screenshots don’t appear — just blank spaces. We’re on a corporate network with a proxy and SSL inspection. We’re mostly printing from the portal (Employee Center style) but sometimes from the platform UI too.
Technician avatar Technician
Great detail — “shows on-screen but disappears in PDF” strongly points to a print/PDF fetch path problem. During print-to-PDF, the browser re-renders the page and may re-request images. With a proxy whitelist or SSL inspection, those image requests can get blocked, timed out, or rewritten — so the text prints but images drop out.

In ServiceNow KB, embedded screenshots typically come from one of these locations:
• sys_attachment download URLs (most common): sys_attachment.do?sys_id=…
• An attachment API route (less common for KB display, but common for integrations): /api/now/attachment/…
• A portal/widget path that ultimately still fetches from attachments

Next, we need one quick “proof test” to separate proxy blocking from ServiceNow configuration:
Test A (fast): open one missing image directly in a new tab (the sys_attachment link). If it fails or redirects to a block page on the corporate network, we’ve confirmed a whitelist/inspection issue.
Test B (control): try printing the same KB article from a different network (mobile hotspot) or from a non-inspected segment. If images print there, it’s 99% a proxy allowlist problem.
Customer
I checked one image link and it’s like sys_attachment.do?sys_id=…. On our network it sometimes opens, but other times it spins or fails. On hotspot it loads instantly. Printing from hotspot also includes images in the PDF. So yes, it’s our proxy.
Technician avatar Technician
Perfect — now we can be very specific: you need a proxy whitelist (allowlist) that reliably permits ServiceNow KB image retrieval during printing.

Step 1 — Whitelist the correct ServiceNow domains (minimum set)
Ask your network/security team to allow outbound HTTPS access (no content rewrite, no caching corruption) to:
• Your ServiceNow instance FQDN(s): <your-instance>.service-now.com (or your custom domain if you use one)
• The specific attachment endpoints used by KB images on that instance, especially:
  — /sys_attachment.do (KB screenshots commonly load here)
  — Any related attachment download routes your environment uses during portal rendering

Step 2 — Decide how SSL inspection should treat attachments
If SSL inspection is breaking image downloads (common with large PNGs or repeated requests), request an exception/bypass for the attachment path(s) on the instance. Many orgs keep inspection for login pages but bypass for attachment binary downloads to prevent corruption/timeouts during print rendering.

Step 3 — Confirm the proxy isn’t stripping content types
KB images require correct headers (image/png, image/jpeg). If the proxy replaces content with an HTML “blocked” page, the print engine drops the image and you get blank spaces in the PDF.
Customer
That makes sense. Our security team asks for exact URLs/patterns to allow. Also, they mentioned “we only allow what’s on the inclusion list.” How do we describe it cleanly? We also print from Employee Center (portal), not just kb_view.do.
Technician avatar Technician
Great — we’ll give them a precise, security-friendly “positive model” request that maps to how ServiceNow serves KB content.

What to send your proxy/firewall team (copy/paste template)
1) Allow HTTPS to your instance host(s):
• https://<your-instance>.service-now.com/ (or your custom instance domain)

2) Allow the attachment image path(s) used by KB articles (critical for “prints no images”):
• https://<your-instance>.service-now.com/sys_attachment.do (with query sys_id)
• If your environment uses API-based attachment fetching for portal widgets, also allow the attachment API routes on the same host (commonly under /api/now/…).

3) If you use Employee Center / Service Portal printing, allow the portal KB page route too (so the page renders consistently):
• https://<your-instance>.service-now.com/sp (and the KB article page route your portal uses, e.g., sp?id=kb_article… )

Why this is needed
The KB text can render even when image requests are partially blocked, but printing triggers fresh requests for the embedded images. If those attachment fetches are blocked or rewritten, the PDF will print with missing screenshots (blank placeholders).

That “inclusion list” language matches a positive security model (allow what’s needed, block everything else). ServiceNow even documents the concept as an inclusion list approach, so your security team’s framing is normal.
Customer
Nice. Another wrinkle: some users can print with images, others can’t, even on the same network. Could that be permissions? Or browser settings? We also saw “broken image” once inside the KB itself.
Technician avatar Technician
Yes — when it’s “some users yes, some users no,” it can be a mix of proxy policy and ServiceNow attachment access. Here’s the quick triage that saves hours:

Triage 1 — Proxy/user policy differences
Many proxies apply rules by user group, OU, device posture, or PAC file. So two users on the “same network” may actually have different inspection policies. If one user’s sys_attachment links open instantly and another gets delays/blocks, that’s almost always proxy policy variance.

Triage 2 — Attachment permissions / ACL
If a user can open the KB text but cannot open the image URL in a new tab (sys_attachment) and gets a permission-style error, then it’s likely an ACL/role issue for attachments (or a restriction on attachments for that table/article). A broken image inside the KB body can also occur if the attachment exists but the user can’t access it.

Triage 3 — Browser print behavior
Chrome/Edge can behave differently on print-to-PDF. If your proxy is “barely allowing” the image fetches, one browser might time out sooner and drop images. Testing Edge vs Chrome is a quick win.

If you tell me what users see when opening the direct sys_attachment link (block page vs permission message vs endless spinner), I can tell you which branch it is immediately.
Customer
For the users who fail, the sys_attachment link often spins and then times out. No clear permission error. For the users who succeed, it loads fast. So likely proxy policy. What’s the “best practice” way to print KB articles so images are included reliably?
Technician avatar Technician
You’re thinking about this the right way: fix the network allowlist, then standardize the print workflow so users aren’t improvising (that’s where “KB prints no images” keeps coming back).

Best-practice print workflow for ServiceNow KB (images included)
1) Prefer a printer-friendly view when available (especially from platform “View Article” / kb_view style pages). It reduces dynamic portal widgets that can lazy-load content during print.
2) Before printing, do a quick “image preload” pass: scroll through the article once so all screenshots load. If images are behind a proxy, this step forces the attachment requests to happen before the print engine snapshot.
3) Then print to PDF (Chrome/Edge). If your proxy sometimes delays attachments, Edge can be more tolerant than Chrome in some environments.
4) If printing from Employee Center is required, make sure the proxy allowlist covers both the portal page route (/sp) and the attachment binary route (/sys_attachment.do). Otherwise the page prints but screenshots vanish.

The real “never fails” fix is the proxy whitelist itself — once sys_attachment is consistently reachable, printing becomes predictable.
Customer
Can we validate the whitelist quickly without involving the whole security team every time? Like a simple checklist: what URLs should load, what network test proves it’s fixed, and what we should capture for troubleshooting.
Technician avatar Technician
Absolutely — here’s a practical validation checklist your admins can run in minutes, focused on ServiceNow KB printing missing images and proxy allowlist success criteria.

Proxy whitelist validation checklist (fast)
1) Open the KB article and confirm images load on-screen (baseline).
2) Right-click one screenshot → “Open image in new tab.” It should open a URL like sys_attachment.do?sys_id=… on your instance and load quickly (no long spinner, no block page).
3) Repeat step 2 for 2–3 images (small + large PNG). If large images fail, it’s often inspection/timeouts rather than outright blocking.
4) Print to PDF and confirm screenshots appear. If the direct image tabs load fast but the PDF still drops images, it’s usually a browser/print timing issue — do a scroll-to-preload pass, then print again.

What to capture if it still fails
• One example sys_attachment URL that times out
• Whether the user is on a different proxy policy group
• Browser (Chrome vs Edge) and whether it was portal (sp) vs kb_view/platform UI

With those 3 items, a network team can usually fix the allowlist rule precisely.
Customer
This is great. One last thing: do we ever need to change ServiceNow settings (like attachment security) for this? Or is it purely network whitelist? We want to avoid weakening security.
Technician avatar Technician
In your case (works on hotspot, fails on corporate proxy), it’s primarily a network allowlist/SSL inspection issue — you shouldn’t need to weaken ServiceNow security settings.

When ServiceNow-side changes are relevant is only when the symptom looks like a permission failure (image URL returns an access error) or only certain audiences (non-licensed users, external users) can’t see KB images even outside the proxy. Then we look at attachment ACLs, knowledge visibility, and whether the portal is serving images under the same auth context.

Since your failing users see timeouts/spinners (not permission errors), the safe path is:
• Keep your ServiceNow attachment security intact
• Fix the proxy whitelist for the instance + sys_attachment path(s)
• Optionally bypass SSL inspection for attachment binary downloads if inspection is corrupting or delaying images during print-to-PDF

If you want, open the chat and paste one failing sys_attachment URL + your proxy vendor name — we’ll give you the tightest allowlist wording with minimal scope.
Customer
Perfect. We’ll request the allowlist for our instance and sys_attachment paths and test with your checklist. If it still fails, we’ll use the chat with an example URL. Thanks!
Technician avatar Technician
You’re welcome! Recap: when ServiceNow KB prints no images, the most common cause is a corporate proxy/content filter blocking or delaying the embedded screenshot requests (usually sys_attachment.do) during print-to-PDF rendering. The fix is a precise proxy whitelist/allowlist for your instance host plus attachment endpoints, and (if needed) an SSL inspection exception for attachment binary downloads so images don’t time out or get replaced by a block page.

If you want, start a chat and we’ll confirm the minimal allowlist rules for your environment (portal + kb_view + attachments) in minutes.

Quick answer: the accepted fix

Accepted fix when ServiceNow KB prints no images: whitelist/allowlist your instance domain and the sys_attachment.do image path in your corporate proxy (and bypass SSL inspection for attachment binaries if needed). Then preload images (scroll once) and print from a printer-friendly view for consistent PDF screenshots.

Why ServiceNow KB screenshots disappear in print preview or PDF

Most ServiceNow knowledge base (KB) images are stored as attachments and rendered via attachment URLs (commonly sys_attachment.do?sys_id=…). On-screen viewing may succeed because the browser loads images gradually and retries in the background. But when you use print to PDF, the page is re-rendered and images may be fetched again. If a corporate proxy whitelist, web filter, firewall rule, or SSL inspection blocks/rewrites those attachment requests, the PDF ends up with missing images (blank placeholders or broken icons).

This is especially common in Employee Center / Service Portal KB pages where some content loads dynamically. A printer-friendly path plus a stable allowlist for the attachment endpoints typically resolves “KB prints no images.”

How to confirm it’s proxy allowlist vs ServiceNow permissions

If the same KB article prints correctly on a hotspot but fails on the corporate network, it’s almost always proxy/content filtering. The fastest proof is to open the embedded image directly (sys_attachment link): if it spins, times out, or shows a block page, you need an allowlist rule. If the image returns a clear access/permission message even off-proxy, then you review attachment ACLs and knowledge visibility instead.

ServiceNow KB prints no images — quick troubleshooting tips

Fix missing screenshots, blank placeholders, and broken KB images in print-to-PDF.

Fast path: allow HTTPS to your instance and whitelist the sys_attachment.do endpoint used by KB screenshots. If SSL inspection is enabled, request an exception for attachment binary downloads. Then preload images (scroll once) and print from a printer-friendly view to keep screenshots in the PDF.

Disclaimer: This information is AI-generated and intended for general guidance only. For advice specific to your ServiceNow instance, portal setup, and corporate proxy rules, please consult a verified expert on Whizz-Tech before changing security configurations.

Getting Started Is Easy

Ask for help, 24/7

Members get round-the-clock access to experts for ServiceNow KB printing, missing images, proxy allowlists, and attachment access problems.

Expert will respond in minutes

We match you with a specialist who knows sys_attachment, printer-friendly KB workflows, and how to build a tight proxy whitelist that keeps KB screenshots in your PDFs.

Save time & money

Stop reprinting broken PDFs. Get a clean, repeatable fix for KB article prints without images — fast.

FAQ

Why does my ServiceNow knowledge article print to PDF with no images?

Most KB screenshots load from attachment URLs (often sys_attachment.do). During print-to-PDF, the browser re-fetches images; if a proxy/content filter blocks or rewrites those attachment requests, the PDF prints with missing screenshots or blank placeholders.

What should we whitelist in the proxy to fix ServiceNow KB missing images?

Whitelist your ServiceNow instance domain and allow the attachment endpoints used by KB images (commonly /sys_attachment.do with sys_id). If SSL inspection causes timeouts/corruption, request an exception for attachment binary downloads on that same host/path.

How do I tell if it’s a proxy issue or ServiceNow permissions/ACLs?

If printing works on a hotspot but fails on the corporate network, it’s proxy allowlist/inspection. If the direct image URL fails everywhere with an access-style message, then review attachment ACLs and knowledge visibility for the affected users.

What’s the most reliable way to print KB articles with screenshots included?

Use a printer-friendly view when possible, preload images by scrolling once, then print to PDF. The key requirement is that attachment URLs load quickly and consistently (proxy allowlist in place) so the print renderer can fetch screenshots.

Sources

Matt Verified Icon
Matt ● replies in < 1 min
Technician Expert
⭐⭐⭐⭐⭐ Trusted by 27,000+ customers
Avatar
Alex · Expert's Assistant
5 Tech Support Specialists are online right now.