No. DeepSeek-R1 takes text in and produces text out. There is no image, audio or video input path in the released model, so anything that arrives as a screenshot, a scanned invoice or a PDF page image has to be converted to text by something else before R1 ever sees it.
That is the whole answer to the modality question. The useful part starts one step later, because “text-only” is not the same as “disqualified”, and most teams that ask the question are not running a fully multimodal workload — they are running a mixed one.
What does “text-only” actually rule out?
It rules out sending pixels. It does not rule out the work. A majority of the prompt distributions we see in screening conversations are text-dominant with a minority of image-bearing items: a contract clause pasted as text, then three pages of a scanned appendix. The mix ratio is the decision variable, not the modality label.
Two claims worth writing down verbatim:
- DeepSeek-R1 is a text-input, text-output reasoning model; image-bearing prompts require an upstream conversion step (OCR or a separate vision-language model) before the reasoner is invoked.
- The conversion step contributes its own error to the pipeline, so a text-only reasoner behind OCR is evaluated on the combined error of extraction plus reasoning — never on the reasoner’s benchmark scores alone.
That second point is where a plain modality answer usually gets mishandled. If Tesseract or a document-understanding VLM drops a table column, R1 reasons correctly over the wrong text and the failure is scored against the wrong component. Any eval harness that puts a conversion step in front of a text-only model needs to log the extracted text, not just the final answer, or the error budget is unattributable.
Quick answer block
| Question | Answer for DeepSeek-R1 |
|---|---|
| Accepts images? | No |
| Accepts audio or video? | No |
| Input | Text (including text extracted from documents by another tool) |
| Output | Text, with visible intermediate reasoning tokens |
| Mixed text + documents-as-images workload | Serviceable behind an OCR or VLM extraction step |
| Fully image-native workload (charts, diagrams, UI screenshots read visually) | Not a fit; needs a vision-language model |
| Answer expiry | Per release. Re-check on any new checkpoint in the family; the family name does not carry the modality scope |
The last row matters more than it looks. Model families ship new members, and a vendor adding a vision-capable sibling does not retroactively change R1’s input scope — nor does R1’s scope constrain the sibling’s. Record the answer against a named checkpoint, not against “DeepSeek”.
Where the answer belongs
A modality answer that lives in someone’s head gets re-derived, usually wrong, a few weeks later. It belongs in the candidate-screening record alongside the checkpoint identity, next to whichever conversion path covers the image-bearing share of prompts. That is the cheapest gate in an evaluation programme: it removes a candidate — or redirects effort to sizing the extraction step — before anyone builds a harness. We treat it as the first line of the screening sheet for exactly that reason.
The parent discussion of how modality, variant identity and serving shape combine into a defensible shortlist is in our evaluation-screening methodology for reasoning models, and the recording discipline around it sits with our work on AI governance and trust.
One open question we do not think is settled: when the extraction step is itself a large VLM rather than classical OCR, is the resulting two-model pipeline still cheaper to govern than a single natively multimodal model of comparable quality? We have seen it go both ways, and the deciding factor was usually how auditable the intermediate text needed to be.
