A client can't play the 4K file you sent.
Diagnose it in order, most likely cause first.

A video file is a container holding streams encoded with a codec. The container is the wrapper, MP4 or MOV or MXF. The codec is what actually turned pictures into data. A client machine needs a decoder for the codec, and its default player needs to recognise the container well enough to look inside. Those are two separate failures with two different symptoms.

The codec failure is total and instant. There is no picture, or a black or green frame, or audio running under nothing. Post-production codecs are the usual cause. ProRes 422, ProRes 4444 and DNxHR are mastering and interchange formats; they are hosted at full size for download rather than played in a browser. Camera RAW is a further step removed again: BRAW, R3D, ARRIRAW, N-RAW, X-OCN and ProRes RAW never stream in a browser, and the honest workflow is to finish to HEVC or ProRes before anything gets sent for review.

The container failure looks different. The player opens, then reports that it cannot read the file, or opens it and finds no video track it recognises. This is where the extension matters. Google publishes the exact list of formats Drive will play: WebM, MPEG4, 3GPP, MOV, AVI, MPEGPS, WMV, FLV, MTS and OGG. Dropbox publishes its own previewable video extensions: .3gp, .3gpp, .3gpp2, .asf, .avi, .dv, .m2t, .m4v, .mkv, .mov, .mp4, .mpeg, .mpg, .mts and .mxf. Neither list is a statement about your client’s desktop, but both are a good proxy for what mainstream software expects to see.

A file that stops playing at exactly the same timecode every time, or that will not open at all despite being the right format, is often a transfer that ended early. Large deliveries fail quietly. A browser tab is closed, a laptop sleeps, a corporate proxy times out, a download resumes into a second copy with a number appended to the name.

The check is exact rather than approximate. Have the client read the file size in bytes, not in gigabytes rounded to one decimal, and compare it with the byte count on your machine. If the two numbers differ at all, nothing about the codec matters yet. There are two related states worth ruling out at the same time. Dropbox documents a preview error for files that are still uploading. Google publishes the message “Video is still processing. Try again later,” and notes that for a large file it may take a while before the video is ready. A link sent the moment an upload bar fills can produce a complaint that has nothing to do with your export.

If the client sees motion and describes it as jerky, stuttering, out of sync or slow, the decoder exists and the machine cannot keep up with it. This is the one cause on the page that no platform decision fixes, because the work is happening on their hardware. 4K on a weak machine plays only when that machine decodes it, and the same caveat applies with more force at 8K.

The test is a ladder you build yourself. Export the same thirty seconds at 1080p in the same codec and send both. If 1080p is clean and 4K stutters, you have measured the ceiling of that machine and you now know what to deliver to that client for the rest of the project. If both stutter, look at the codec first, because a machine with no hardware path for a format will fall back to software decoding and behave exactly like a machine that is too slow.

We publish no decoder bitrate ceiling and no maximum resolution, because we enforce neither. The only hard limit anywhere in the upload path is 50 GB per file, checked in the browser before the first part is sent. Anyone quoting you a specific megabit figure at which consumer decoding fails is guessing; the honest test is the one above, run on the machine that has to play it.

Here, both jobs run off the same stored object. The player streams the exact bytes you uploaded, with no encode step at upload and none at playback, so nothing is quietly substituted between your export and their screen. There is no bitrate ceiling and no resolution ceiling on our side; what plays is decided by the viewer’s browser and hardware, which is why the diagnosis above matters more than any platform feature.

Download is a switch on each individual film, not an account setting and not a paid extra. Turn it on and the viewer gets the exact file you uploaded, byte for byte, straight from the watch page. Leave it off and no download link is ever generated. That is the whole delivery: the producer clicks play, the post house clicks download, and both are looking at the same object. The player itself carries no platform logo, no ads, no suggested videos and no end screen, on the free plan exactly as on the paid ones. The only logo it can show is one you upload yourself.

The client is on a five-year-old laptop with integrated graphics, or on a locked-down corporate machine where they cannot install a player, or on a connection that will not carry a heavy master no matter who serves it. Nothing about hosting changes any of that. Removing an encode step does not add a decoder to their computer, and a link that streams a 4K master to a machine that cannot decode 4K produces exactly the same complaint as the file did.

In that situation, the right answer is a smaller export. Give them 1080p in H.264, at a sensible bitrate, and let them approve the cut on something they can actually watch. Keep the 4K master hosted with download switched on for whoever has the hardware for it. That is not a compromise on your work; it is a recognition that a client approving a picture on a machine that cannot show it is not approving anything useful. Change the export before you change the platform.

Change the platform when the pattern is different: when the file itself is fine, the machine is fine, and the thing in the middle is what keeps degrading, delaying or refusing the delivery. That is when byte-for-byte streaming plus a per-film download earns its place, and 5 GB of storage on the free Starter plan, one film at a time, is enough to run the test on your own footage and your own client before you decide.