Upload a video to an AI model: the six in MultiChats that can read one
Six of our 59 models accept a video file and all six are Gemini. Here is the upload path, the real limits, and what the model can tell you.
Of the 59 models in MultiChats at our 19 October 2026 check, six accept a video file: Gemini 3.8 Flash, Gemini 3.6 Flash, Gemini 3 Flash, Gemini 3.5 Flash Lite, Gemini 3.1 Flash Lite and Gemini 2.5 Flash Lite. All six come from Google. No model from any other maker in our catalogue takes video at all, and the upload itself sits behind the Pro+ plan, so you need both Pro+ and a compatible model to attach a clip.
For comparison, 46 of the 59 read images and 24 read PDFs. Video is the narrow one.
What follows is the path in order, and the places it goes wrong.
What the model does with the file
Google's documentation is specific. In its default processing mode, Gemini "samples the video at a rate of 1 frame per second", and audio "is processed at 1Kbps (single channel)" (Gemini API docs, checked 2 October 2026). One frame per second is a lot of frames across a five minute clip, and it is still a sample. Whatever happened between two sampled frames was never seen.
So a summary, "what are the steps being shown here", "does this clip contain a shot of X", "what does she say about the refund policy" are all fair asks. Frame-accurate timing is not one. Google's own guidance is to refer to moments in "MM:SS" format, which is roughly the resolution the model works at.
Two things we will not promise. Speaker identification, meaning which named person said which line, is not something Google's page offers and not something we have tested, so treat any name the model attaches to a voice as a guess. And nothing here is live watching. The file is uploaded, sampled and read after the fact. There is no way to point a camera at something and have a model narrate it as it happens.
Step 1. Check the plan before you go looking for a file
Video upload requires Pro+, which is $34.99 a month or $349.99 a year (plans). Free and Pro accounts are stopped at the attach step with "Video uploads are a Pro+ feature", and stopped again server-side with a 402 if anything gets past the client.
Heads up. Depending on the app version you are on, a large clip on the Free or Pro plan may be refused for its size before you are told that video needs Pro+. A free account attaching a 40MB clip can see "Free plan supports files up to 10MB", which is true and is not the reason a video would have been refused; Pro accounts can see the same message shape at 20MB. Newer builds put the plan message first. Either way, if you are on Free or Pro and a video will not go through, the plan is the answer whatever the size message says.
Step 2. Switch to one of the six
Open the model picker and look for the red Video pill on the model card. Its tooltip reads "Supports video upload and analysis", and only the six Gemini entries carry it. The model info card shows the same Video marker alongside Vision and PDF, so you can confirm before you commit to a thread.
Three of the six, the Flash Lite entries, sit on the free plan's model list. That changes nothing about the upload. The model gate and the plan gate are separate checks and a video has to clear both. In the other direction, a Pro+ account sitting on a non-Gemini model gets "This model doesn't support video. Switch to a Gemini model to send videos."
Step 3. Attach a container it can actually read
The accepted extensions in our registry are mp4, mov, webm, avi, mpeg, mpg, wmv, flv and 3gpp. That set matches the formats Google lists for the API.
Warning. .mkv is absent from that list by design, because Gemini rejects it. On mobile you find out immediately: the picker refuses the file with "Unsupported video format". On web the file attaches and uploads, and the failure only surfaces once the request is already in flight. If your clip is an .mkv, remux or re-export it to .mp4 first and save yourself the round trip.
Step 4. Watch the length, because the binding limit here is ours
Pro+ caps any single file at 200MB, and bytes are the only hard limit in the upload path. There is no duration check anywhere in it, so bitrate decides how many minutes fit under the cap.
Recordings straight off a phone run somewhere around 1 to 2MB per second in the traffic we see, which puts an untouched camera clip at roughly two to three minutes before it hits 200MB. A heavily compressed screen recording can run an order of magnitude lower and gives you far longer. Two files of the same length can land on opposite sides of the cap, and the difference is entirely in how they were encoded.
Google's ceiling is much further out. A model with a 1M context window "can process videos up to 3 hours long by default (at low media resolution), or up to 1 hour long at high media resolution". You will meet our 200MB long before you get near three hours.
Length costs context as well as bytes. Every second of video is priced in tokens, so a long clip fills a thread quickly, and the context meter under the composer will start telling you when answer quality is likely to slip for the model you picked. If you intend to ask a dozen follow-up questions about one clip, open a fresh thread and make the video the first thing in it.
Step 5. Ask in the shape the model can answer
Prompts that work with a once-per-second sample:
"Summarise this in ten bullets, each with an MM:SS marker."
"List every menu the person opens, in the order they open them."
"At 02:14 there is an error dialog. Quote the text in it."
"Between 00:30 and 01:10, what changes on screen?"
Ask it to quote on-screen text rather than describe it, because a quote is checkable against the frame and a description is not. If an answer looks wrong, name the timestamp in your follow-up. A timestamp gives it somewhere specific to look.
When it will not work, and what to send instead
The clip is too big. Trim it before uploading. Most phone gallery apps trim and re-export in place, and cutting the dead thirty seconds at either end often does it.
It is a screen recording. Re-export at a lower resolution or frame rate. A 1080p30 screen capture holds up fine for reading menus and dialogs.
You only need a few moments. Pull two or three stills and send them as images. Stills work on 46 of the 59 models, and they cost a fraction of the context.
The value is in the speech. The uploader does not take audio files at all. It takes images, PDFs, text and code files, Office documents and video, and hands anything else back with "This file type isn't supported." If a recording is mostly someone talking, paste a transcript as text instead, which Pro and Pro+ accounts can attach as a file.
What we could not confirm
We verified the model set, the plan gate, the format list and the size cap in our own code before publishing this. We did not verify speaker identification, and we did not test how faithfully the audio track is transcribed, so neither is claimed above. Google documents that audio is processed; what a given clip yields is a question for your clip.
A video carries faces, voices and whatever was on the wall behind you, so it is worth knowing where it goes. We do not train on your conversations. Some providers might, depending on the model you pick, and each model's info card carries that notice when there is one. None of the six here carries one. All six are Google models, so Google is where your clip gets read.