# DeepSeek's Vision API: What It Can Do and Where It Falls Short

DeepSeek expanded its V4 Flash family into multimodal AI on August 21, 2026 with `deepseek-v4-flash-vision-exp`, an experimental model that added image understanding without changing the token pricing of the text-only Flash model. At roughly **$0.22 per million input tokens**, it quickly stood out as one of the cheapest vision APIs available.

That experimental model has since been superseded by **DeepSeek V4.1 Flash**, released on September 10, 2026. Multimodal support is now built directly into the main `deepseek-flash` model, so you no longer need a separate vision-specific endpoint. The older `deepseek-v4-flash-vision-exp` model ID still works, but requests now route to V4.1 Flash.

This article looks at **how DeepSeek accepts and processes images**, what happens before inference, and how well the model performs in practical vision tasks. We will test it across **OCR, object identification, and outdoor scene recognition**, then compare the results directly with Claude's vision output.


<iframe class="aspect-video h-auto" width="100%" height="315" src="https://www.youtube.com/embed/ttak9mHz4_Q" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>


## Three ways to send images

The API follows the standard OpenAI-compatible Chat Completions format. Images travel alongside text in the `content` array of a user message, using the `image_url` type.

### Base64 inline

Encode the image as a Base64 string and embed it directly in the request:

```json
{
  "model": "deepseek-flash",
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "What is in this image?" },
        {
          "type": "image_url",
          "image_url": {
            "url": "data:image/jpeg;base64,{b64_encoded_image_string}"
          }
        }
      ]
    }
  ]
}
```

![A code snippet demonstrating how to structure an API call with a Base64 encoded image.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/82fe1302-ddeb-4ca8-635e-c0d4a7955100/lg1x =1920x1080)

The total request payload cap is 48 MB. Base64 encoding inflates file size by roughly 33%, so this method is practical only for smaller images. Use it when images are transient and you want a single self-contained request.

### External URL

Point the API at a publicly accessible image URL:

```json
{
  "model": "deepseek-flash",
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "Please describe this image." },
        {
          "type": "image_url",
          "image_url": {
            "url": "https://example.com/path/to/image.jpg"
          }
        }
      ]
    }
  ]
}
```

The image can be at most 32 MB and must download within 60 seconds. The URL must be publicly accessible. Use this when images are already hosted in cloud storage.

### Files API upload

For large images or repeated use of the same image across requests, upload via the Files API first and reference the returned file ID in the message. This is the most efficient path for batch processing pipelines where the same images appear in multiple requests.

## How the model processes images

Before inference, DeepSeek automatically resizes images based on their dimensions:

- Images below a threshold are scaled up to approximately 384×384 pixels
- Images above a threshold are scaled down to fit within approximately 800×800 pixels
- Aspect ratio is always preserved

![A graphic illustrating how DeepSeek scales both small and large images while maintaining aspect ratio.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/c1ae4305-6e17-457a-80aa-52a0912bc200/lg1x =1920x1080)

Images are billed at a maximum of 1,024 input tokens per image regardless of size. Multiple images in one request are counted independently.

The resizing is the most important thing to understand before relying on the API for OCR. A high-resolution image containing small text gets scaled down before the model sees it. Text that was legible at full resolution can become blurry after resizing. This is the root cause of most of the OCR failures in the tests below.

## API documentation overview

![A screenshot of the official DeepSeek Vision API documentation, highlighting the model's capabilities.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/9a0ec7e7-cbd2-4c46-223f-ab87168ea100/md2x =1920x1080)

The documentation describes the model as suited for describing pictures, reading text from screenshots, analyzing charts, and multimodal agent workflows that interleave text and images. These use cases align with the actual benchmark results: the model performs well on clean screenshots and charts, and less reliably on dense small-text OCR.

## Real-world tests: 14 images across four categories

The tests below compare `deepseek-v4-flash-vision-exp` directly against Claude's vision output on the same images. The comparison isn't about which model is better overall; it's about where the cost-to-accuracy trade-off is acceptable.

### OCR: nutritional label

A close-up of a nutritional label on a jar of almond butter. Classic OCR challenge: small fonts, tabular layout, potential glare.

DeepSeek extracted most of the text and recognized the table structure, but misread the "Per 15g" serving size column as "Per 30g" and had minor errors in some nutritional values. Claude's transcription was nearly flawless.

![A side-by-side comparison of DeepSeek's and Claude's text extraction from the almond butter nutritional label, clearly showing the discrepancy.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/afb9d568-b987-4832-6b75-f382d7018300/lg2x =1920x1080)

The serving size error is directly attributable to the image downscaling. At full resolution the "15g" is clear; after the image is scaled to fit the 800×800 box, the text degrades enough to cause a misread. For applications requiring precise nutritional data extraction, this failure mode is a real risk.

### OCR: branded packaging front

Front of the same jar. The main "SMOOTH Almond BUTTER" text is large and high-contrast. Both models read it correctly. Claude additionally read a small circular badge in the top right that said "NO PALM OIL EVER." DeepSeek missed it.

The pattern holds: large clear text is reliable, fine details are not.

### Object identification: apple

A photo of an apple on a shelf.

DeepSeek identified it as a "yellow peach." Claude identified it as "an apple, most likely a Gala." This is a straightforward object recognition failure, not an OCR issue. For applications that depend on accurate food or product identification, this result is a concern.

### Object identification with hallucination: Jammie Dodgers

A packet of Jammie Dodgers biscuits with promotional text. DeepSeek correctly read the stylized "Jammie Dodgers" font and "WIN A TRIP TO FLORIDA." It also identified "Minions" printed on the packet, then added "THE RISE OF GRU" — a film title not printed anywhere on the packaging. Claude read all text correctly without adding anything not present.

This is a training data association overriding visual evidence: the model knows Minions and The Rise of Gru are connected and generated the film title from memory rather than from the image. For any application where accuracy to the source image matters, hallucination like this is a critical failure mode to test for.

### Outdoor recognition: leaf

A photo of a leaf on the ground taken in the UK. DeepSeek identified it as an "American Sycamore" leaf. Claude noted "In a UK park this is almost certainly London plane." Claude's identification is more plausible in context.

![The two models' differing analyses of the leaf, showcasing Claude's superior contextual reasoning.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/05d3c9c3-67d4-4fd5-f3d3-1e5fdc204200/md2x =1920x1080)

### Outdoor recognition: common objects

Street lamps, park benches, and a Tesla Model 3: both models performed on par, correctly identifying all objects with similar levels of detail.

![DeepSeek's highly accurate and detailed identification of a Tesla Model 3, demonstrating its capability with complex, branded objects.](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/dd394e71-ab21-47fd-3c8c-ad52d954d200/lg2x =1920x1080)

## Where it works and where it doesn't

DeepSeek's vision model is most reliable when the visual signal is clear. **Large, high-contrast text, common objects, and broad scene descriptions** are all areas where it performs well. Accuracy drops once the task depends on small text, degraded images, subtle visual details, or distinctions that are difficult to verify without comparing the answer directly against the source image.

The pricing makes that trade-off interesting. With each image consuming at most 1,024 input tokens, **the cost per image is low enough to make high-volume processing practical**, especially in workflows where a small error rate is acceptable.

That makes it a reasonable fit for tasks such as basic content moderation, object tagging across large datasets, reading standardized documents with clean text, and analyzing UI screenshots. The risk increases when precision matters more than throughput. **Nutritional label extraction, product verification, and other workflows where a hallucinated detail can trigger a downstream error need much more careful validation.**

The `experimental` suffix on the original model was therefore meaningful. The model was useful, but its vision capabilities still had clear reliability limits. V4.1 Flash now carries that multimodal support forward, although it is not yet clear from published testing whether those weaknesses have materially improved.

For that reason, **testing the model against your own image corpus matters more than the headline price**. A cheap vision API is valuable only if its error rate is acceptable for the specific images and decisions in your pipeline.

The current DeepSeek API documentation is available at [api-docs.deepseek.com](https://api-docs.deepseek.com), where you can find the active model IDs, pricing, and the vision-specific resizing and token-counting rules.
