Claude API Vision: Image Input Support Explained

Does the Claude API support image input?

Yes. Claude's API supports vision natively through the Messages API — you can send one or more images alongside text in a single request and Claude will describe, analyze, extract data from, or reason about the visual content. This works the same way as text prompts: images are passed as content blocks inside a message, and the model's response comes back as regular text (or structured tool output if you're using tool calling).

This article covers exactly how image input works, what formats and sizes are supported, common failure modes, and how to wire it up quickly — including through SubToAPI if you want a simplified HTTPS layer on top of your existing Claude access.

How image input works in the Messages API

Instead of a single text string, a message's content field becomes an array of content blocks. Each block has a type — either text or image. For images, you provide the data as base64-encoded bytes along with a media type.

{
  "model": "claude-opus-4",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "image",
          "source": {
            "type": "base64",
            "media_type": "image/png",
            "data": "iVBORw0KGgoAAAANSUhEUgAA..."
          }
        },
        {
          "type": "text",
          "text": "What's in this screenshot? List any errors visible."
        }
      ]
    }
  ]
}

Key points:

• Order matters for clarity. Putting the image block before the text instruction tends to produce more grounded answers, since Claude processes the image context first.
• Multiple images per message are supported. You can send several images in one content array — useful for comparing two screenshots, a before/after pair, or a multi-page document.
• No separate vision endpoint. There's no /vision route — it's the same /v1/messages call used for plain text, just with richer content blocks.

Supported image formats and limits

Claude accepts the common web image formats:

• JPEG
• PNG
• GIF (static)
• WebP

Practical limits to plan around:

• Keep individual images under a few megabytes — very large files increase latency and token cost.
• Extremely high-resolution images get downscaled internally, so there's no benefit to sending beyond what the model actually needs to read (e.g., don't send a 6000px screenshot to read a small table — crop it first).
• Image content consumes tokens just like text. A dense, high-resolution image costs meaningfully more tokens than a simple diagram, so budget accordingly if you're processing images at volume.

Common use cases for Claude's vision support

• Document and invoice parsing — extracting line items, totals, and dates from scanned receipts or PDFs converted to images.
• UI and QA review — feeding screenshots of a web app and asking Claude to flag layout bugs or accessibility issues.
• Chart and diagram interpretation — summarizing a graph, flowchart, or architecture diagram in plain language.
• Content moderation — checking uploaded images against policy descriptions before they're published.
• Accessibility tooling — auto-generating alt text for images at scale.

A typical pattern is combining vision with tool use: Claude reads an image, extracts structured data, and calls a function with that data (e.g., create_invoice_record) rather than just returning prose. See /docs/tools for how tool calling integrates with any content type, images included.

Sending images through SubToAPI

If you're already using SubToAPI to turn your Claude access into a standard HTTPS API, image input works the same way — you just point requests at your sub_live_ key instead of managing provider credentials directly.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-4",
    "max_tokens": 1024,
    "messages": [
      {
        "role": "user",
        "content": [
          {
            "type": "image",
            "source": {
              "type": "base64",
              "media_type": "image/jpeg",
              "data": "/9j/4AAQSkZJRg..."
            }
          },
          { "type": "text", "text": "Summarize the chart in this image." }
        ]
      }
    ]
  }'

This is identical in shape to the direct Messages API — SubToAPI doesn't add a different image format or require pre-processing. The benefit is that your application API key, usage metadata, and billing all live in one dashboard, which matters once you have multiple services or team members sending image requests. Full request/response shape is documented at /docs/messages, and /docs/quickstart walks through generating your first key.

For high-volume image pipelines (batch invoice scanning, screenshot QA in CI, etc.), streaming responses aren't usually necessary since image analysis tends to produce a single structured answer — but if you do want token-by-token output for longer descriptive responses, that's covered in /docs/streaming.

Practical tips for reliable vision results

• Crop before sending. Isolate the relevant region of a screenshot or document instead of sending the whole page — it reduces tokens and improves accuracy.
• Be specific in the instruction. "What's in this image?" gets a generic description; "List every line item and its price from this receipt" gets structured, useful output.
• Pair vision with JSON output when extracting data. Ask Claude to return a JSON object with explicit fields, then validate it in your application code.
• Test with real-world image quality. Lighting, skew, and compression artifacts in production photos behave differently than clean test screenshots — validate on representative samples before shipping.
• Watch token cost at scale. If you're processing thousands of images (e.g., document archives), track usage per request so costs don't surprise you — this is easier when usage metadata is visible per key, as it is in the SubToAPI dashboard.

Questions

Does Claude API vision support require a separate model or endpoint? No. Vision is built into the standard Claude models that support it — you send image content blocks through the normal /v1/messages endpoint alongside text.

Can I send an image by URL instead of base64? The standard approach is base64-encoded image data embedded directly in the request. If your images live remotely, download and encode them server-side before sending.

How many images can I include in one request? You can include multiple image blocks in a single message's content array. There's no fixed "one image per call" restriction, though total payload size and token cost increase with each added image.