Vision — sending images alongside text — is one of the core Claude capabilities available on every platform, Bedrock included. The mechanics differ from what teams sometimes expect, though: on Bedrock there is no "give the model a URL" option. URL input sources for images and documents are not supported there, so every image travels inside the request payload as encoded bytes. That single fact shapes everything below.
Images in InvokeModel: the base64 content block
On the pass-through InvokeModel path, the body is Anthropic's Messages format, and images are typed content blocks inside a message's content array: {"type": "image", "source": {"type": "base64", "media_type": ..., "data": ...}}, where media_type declares the image format and data is the base64-encoded file. A message can mix image blocks and text blocks, so the natural pattern is image first, then the question about it:
import base64
from anthropic import AnthropicBedrock
client = AnthropicBedrock(aws_region="us-east-1")
data = base64.standard_b64encode(open("invoice.png", "rb").read()).decode()
msg = client.messages.create(
model="global.anthropic.claude-opus-4-6-v1",
max_tokens=1024,
messages=[{"role": "user", "content": [
{"type": "image", "source": {"type": "base64",
"media_type": "image/png", "data": data}},
{"type": "text", "text": "Summarize this invoice for accounts payable."},
]}],
)
print(msg.content[0].text)The example uses Anthropic's AnthropicBedrock Python client (pip install -U "anthropic[bedrock]"), which rides the standard AWS credential chain; the identical JSON body works through boto3's invoke_model if you prefer the AWS SDK — see InvokeModel in depth for that variant.
Images in Converse
Bedrock's unified Converse API also accepts images for Claude, as image content blocks within a message — carrying the image bytes plus a format identifier, in Converse's own block shape rather than Anthropic's. Your SDK typically handles the byte encoding for you; consult the AWS Converse API reference for the exact field names in your language. Functionally the result is the same: the model sees the image in context and can answer questions about it, and multi-turn conversations can accumulate several images across turns. Which API to standardize on is a broader decision covered in InvokeModel vs Converse.
The limits that bite in production
Payload size. Bedrock caps request payloads at 20 MB — and base64 encoding inflates files by roughly a third, so budget accordingly. High-resolution scans and multi-image requests hit this ceiling faster than teams expect; downscaling images before encoding is the standard mitigation and usually costs nothing in answer quality for documents.
Image counts and context. Anthropic's documentation puts a per-request ceiling of up to 600 images or PDF pages on 1M-token-context models, and 100 on 200K-context models. Every image also consumes context-window tokens, and image tokens are billed as input like any others — so a pipeline that sends 40-page scanned documents should be costed before it ships, not after.
Logging behavior. If you enable Bedrock's model invocation logging, note that inline log entries carry input/output JSON only up to 100 KB; larger bodies and binary data such as images are delivered to your S3 bucket under a data prefix instead. Plan bucket permissions and retention with images in mind.
PDFs are a close cousin
Scanned documents often arrive as PDFs rather than images, and Bedrock supports PDF input for Claude through both Converse and InvokeModel — with a wrinkle: on Converse, full visual PDF analysis requires citations to be enabled, otherwise you get basic text extraction only, and Anthropic recommends InvokeModel for full control. If your real workload is documents rather than photographs, weigh the PDF path before building an image-conversion pipeline.
Where to go next
See vision for documents for use-case patterns, the boto3 setup guide to get your environment ready, or the feature matrix for what else Bedrock does and doesn't support.