Image URL / Base64 not returned in Chat API response

[bipin-adh]

Hi everyone,

I noticed an inconsistency when retrieving images between the Chat Platform UI and the Chat API.

When images are uploaded or sent in the Chat Platform, they appear correctly when retrieved through the PageIndex interface. However, when accessing the same messages via the Chat API, the response only includes the image description, but the image URL or Base64 representation is missing.

What I observed

PageIndex retrieval (UI): Image is visible and accessible.

Chat API response: Only the image description is returned.

Missing: Image URL or Base64 data.

Expected behavior
The Chat API response should include either:

an image URL, or

the Base64 encoded image data,

similar to what is accessible via the platform interface.

Is this the expected behavior of the API, or could this be a bug or a missing field in the response?

If anyone has experienced this or knows the correct way to retrieve image data from the Chat API, I’d really appreciate the guidance.

Thanks!

[Manoj-Gujare]

Hi @bipin-adh
This is very likely expected behavior, and it comes from how PageIndex separates retrieval from asset rendering.

---

What’s happening

• In the PageIndex UI:

  • The UI acts as a full client layer
  • It retrieves semantic results AND resolves asset references (images) from storage
  • That’s why images are visible there

• In the Chat API:

  • The response is focused on the LLM output (text + descriptions)
  • It does not automatically inline binary/image data (URL/Base64)

So the API is returning retrieval results, while the UI additionally handles rendering.

---

Where the image data usually is

In most RAG-style APIs, images are not embedded directly in the message content.

Check the response JSON for fields like:

• metadata
• citations
• source_nodes
• page_id / node_id / document_id

These often contain references to the original content.

---

Typical retrieval flow

1. Call Chat API → get:

   • text response
   • references (node/page IDs)

2. Use those references to:

   • fetch the original document/page
   • or call a separate asset endpoint (if available)

3. Resolve:

   • image URL
   • or Base64 data

---

Why images are not returned directly

This is usually intentional:

1. Payload size

   • Base64 images would make responses very large

2. Separation of concerns

   • API = retrieval
   • storage layer = asset delivery

3. Security

   • images may be stored in private buckets (signed URLs required)

---

What to check

• Does the API response include:
  • page_id or node_id?
• Is there:
  • an asset endpoint (e.g., /assets/{id})?
• Any flags like:
  • include_metadata
  • include_assets
  • raw_content

---

When it would be a bug

Only if:

• The API documentation explicitly says it should return image URLs/Base64
• Or a parameter exists to include images but it’s not working

---

Suggestion

If your use case needs images in the response:

• Add a post-processing step:
  • map node/page IDs → fetch images from storage
• Or request a feature like:
  • include_images=true in the API

---

Summary

• UI shows images because it resolves asset references
• API returns descriptions because it focuses on semantic retrieval
• You typically need a second step to fetch actual image data

[bipin-adh]

Hi @Manoj-Gujare , thanks for the detailed analysis.
I managed to get the image base64 url i need along with image description from the pdf having tables, text, formulas and figures.

It was not present in api but when i used mcp of pageindex got the image url as well.Its internally calling get document image tool by passing image path as argument.