What format will the video be delivered in?

"What format will I get it in?" is the question that separates a well-managed video delivery from a nightmare. It sounds trivial, but behind it lie decisions that determine whether the piece can be broadcast, edited later, archived, recompressed for social media, or handed to a client without problems.

Most of the disputes that end up in back-and-forth emails —"this won't open," "it looks pixelated," "it's too heavy to upload," "we want to change the subtitle and we can't"— are settled at the moment you request the format, not when you receive the file. This guide explains what to ask for, in what order, and why.

Container and codec are not the same thing

The first vocabulary mistake, and the one that causes the most confusion, is treating "MP4" or "MOV" as if they were video formats. They aren't. They are containers —boxes that wrap one or more data streams.

The codec is what lives inside: the algorithm that compresses the video and audio. A single MP4 file can contain H.264, H.265, or AV1 video; AAC, MP3, or Opus audio. A MOV file can carry H.264 or ProRes. When someone says "I need an MP4," what matters is understanding: with which internal codec, at what bitrate, in what resolution.

The main containers and what they're for:

• MP4 (officially MPEG-4 Part 14, ISO/IEC 14496-14, standardized in 2003): the most universal. It works in practically every player, browser, and platform. It's the default choice for digital deliveries, social media, and web publishing. Almost always with an H.264 or H.265 codec.

• MOV (QuickTime, Apple's proprietary format since 1991): flexible, supports more codec types and professional metadata. It's the usual container in editing workflows —ProRes, intermediate codecs, files with several audio tracks. It plays without issue on macOS and Windows with the appropriate codecs, but some web platforms don't accept it directly.

• MKV (Matroska, 2002): an open container, very capable —it supports multiple audio tracks, embedded subtitles, chapters. Popular in distribution and archiving, less so in commercial delivery because not every platform accepts it.

• WebM (Google, 2010): an open, web-oriented container, usually carrying VP9 or AV1. Useful for serving video on your own sites when you control the player; it doesn't work as a generic delivery because some contexts don't support it.

• AVI (Microsoft, 1992): legacy. It shows up in old files but isn't used for modern professional deliveries.

The operating rule: ask for MP4 when the destination is generic digital publishing; MOV when there's later editing, retouching, or a professional workflow; WebM only when publishing in your own player that supports it; MKV for high-capacity personal archiving. Everything else is usually legacy.

Masters, intermediates, and deliveries: three different things

One of the most expensive points of confusion is failing to distinguish between master, intermediate, and final delivery. All three are video files, but they have different functions and different formats.

The master is the highest-quality file from which all versions are generated. It lives in the studio's archive forever. It's never published. If three years from now you need a new version —subtitles in another language, a vertical crop, a duration adjustment— you go to the master.

The reasonable choice for a master is a codec with little or no perceptual compression: ProRes 422 HQ or ProRes 4444 (the latter if there's an alpha channel or critical graphics), from Apple, launched in 2007 to replace tape-based workflows in professional editing; or DNxHR HQ/HQX, from Avid, a functional equivalent used mainly in Avid Media Composer workflows. Both produce heavy files —one minute of ProRes 422 HQ at 1080p comes in around 1.2 GB, rising to 5-7 GB at 4K— but that weight is deliberate: it's what lets them survive future recompressions without visible degradation.

An intermediate is what circulates between phases of the workflow. Material for color, for sound correction, for internal review. It's also usually ProRes or DNxHR, possibly a lighter one (ProRes Proxy, ProRes LT) if bandwidth is a problem.

The final delivery is what reaches the destination —channel, platform, client. Here everything changes: the priority is no longer preserving quality for re-editing, but producing a reasonably sized file that plays well at the destination. MP4 with H.264 is still the safe choice for almost any commercial destination; H.265 offers a smaller size at equal quality but with slightly more limited compatibility. To decide case by case, it helps to know how to choose between H.264 and H.265 based on destination and compatibility.

Asking for "the final file" without specifying what it's for leads to misunderstandings. The right approach is:

• "I need the archivable master in ProRes 422 HQ" (for my archive).
• "I need the YouTube delivery in MP4 H.264" (to publish).
• "I need a clean version without final graphics for future adaptations" (for re-edits).

These three are different deliveries. Asking for "the final file" without further detail forces the producer to guess.

What to ask for based on destination

This is the practical part: what specific format to request for each common destination in 2026.

YouTube. MP4, H.264 or H.265 codec, 1080p or 4K resolution, frame rate identical to the shoot (24, 25, 30, 50, or 60 fps; never convert frame rates), AAC stereo or 5.1 audio, bitrate per YouTube's recommendations (around 8 Mbps for 1080p30, 12 Mbps for 1080p60, 35-45 Mbps for 4K30). YouTube recompresses everything you upload: uploading an uncompressed master is wasting upload time without gaining final quality.

Vimeo. Accepts higher quality than YouTube and better preserves the source. MP4 H.264 with a higher bitrate (10-20 Mbps for 1080p), AAC audio. For professional review workflows, it also supports H.265 and more generous files.

Meta (Facebook and Instagram). MP4 H.264, AAC audio. It recompresses aggressively, so it's best to upload versions already optimized to the correct size: 1080×1080 for square feed, 1080×1350 for vertical feed, 1080×1920 for Reels and Stories.

TikTok. MP4 H.264, vertical 9:16, ideally 1080×1920, AAC audio. Uploading directly from the app usually recompresses more than uploading from desktop or scheduling through the management API.

LinkedIn. MP4 H.264, 16:9 or 1:1, AAC audio, a maximum of 5 GB and 10 minutes for ads. Subtitles burned in or as a separate SRT file.

X (Twitter). MP4 H.264, a maximum of 512 MB and 140 seconds on a standard account (more on verified accounts), AAC audio.

Email marketing. Ideally, you don't include video as an attachment. You upload it to your own page or to YouTube/Vimeo and link to it. If you have to attach it, MP4 H.264 at the lowest possible weight (rarely above 5 MB).

Event screen or digital signage. It depends on the medium. The usual: MP4 H.264 at the screen's native resolution, audio if the screen plays it. Some signage systems use proprietary formats (JPEG2000, MXF), so it's worth confirming beforehand.

Your own website. MP4 H.264 as a universal fallback; ideally WebM with AV1 or VP9 as the primary source for its smaller size, with <source> tags offering both to the browser. For short looping background clips, H.264 is still the safest route.

TV broadcast. Format defined by the channel. Common: MXF (Material eXchange Format, standardized by SMPTE in 2004) with XDCAM HD 50, IMX, or ProRes 422. Loudness EBU R128 (-23 LUFS in Europe, -24 LKFS in the US under the CALM Act). Each channel publishes its technical specifications; agreeing to meet a broadcast requirement without that specification is a guarantee of rejections.

Cinema/projection. DCP (Digital Cinema Package), MXF with JPEG 2000, a very specific format prepared with dedicated software. It's almost always outsourced to DCP mastering houses.

Subtitles: the most underestimated decision

How subtitles are delivered greatly changes the usefulness of the file later on.

Burned-in subtitles. They're part of the image; they can't be removed or translated. Advantage: they're guaranteed to be seen on any player, even on social networks that play without sound by default (more than 80% of in-feed consumption). Disadvantage: producing versions in other languages requires re-rendering the entire video. For Reels, TikTok, and Shorts, they're the right choice —they serve silent consumption by design. For YouTube on desktop, they're not ideal: they block YouTube's automatic subtitles and translation.

Subtitles as a separate file (sidecar). They come in standalone files:

• SRT (SubRip): the most universal. Plain text, supported by almost everything. Limited styling.
• VTT/WebVTT: the W3C standard for HTML5 video, supports more styling and positioning.
• ASS/SSA: an advanced format with detailed styling, popular in distribution.
• CEA-608/708: closed captions for broadcast, embedded in the stream.

For digital deliveries, SRT and VTT cover most cases. For broadcast, you have to comply with CEA-708.

The practice that ages best: always ask for a separate SRT from the file, even if a version with burned-in subtitles is also delivered. The SRT allows translations, text edits, and reuse. The burned-in version covers the channels that don't read external subtitles (Reels, TikTok, Stories).

Resolution, frame rate, and color: three constants worth locking down

Three more parameters that are neither container nor codec, but that shape the delivery.

Resolution. Common today: 1920×1080 (Full HD), 3840×2160 (4K UHD). 8K (7680×4320) exists but is rarely an actual destination. The rule: shoot at the highest reasonable resolution and deliver at the one the channel uses. Lowering resolution is trivial; raising it is impossible without losing quality.

Frame rate. In Europe the traditional baseline is 25 fps (inherited from PAL); in NTSC markets, 30 (technically 29.97). For cinema, 24 fps. For fast motion —sports, gaming— 50 or 60 fps. The most important operating rule: don't convert frame rate between source and delivery. If the camera shot at 25 fps, deliver at 25. If it shot at 24, deliver at 24. Forced conversions (24→30) produce visible motion artifacts ("judder").

Color space. For web and HD broadcast delivery, Rec.709 (BT.709) is still the standard. For 4K HDR, Rec.2020 with HDR10, Dolby Vision, or HLG. Delivering a file mastered in Rec.2020 to a destination that only supports Rec.709 produces dull, desaturated colors; the reverse produces out-of-gamut colors. Confirming the color space before exporting avoids a silent rejection —where the file "displays" but the colors are wrong.

Audio. For digital delivery, AAC stereo at 192-320 kbps or 5.1 if the destination warrants it. For masters, PCM (uncompressed) at 48 kHz, 24 bits. Loudness adjusted to the channel: -23 LUFS for European broadcast, -14 LUFS for streaming, -16 LUFS for podcast.

Naming as part of the delivery

The last thing that seems to matter and the thing that ends up mattering most six months later: how the files are named. A delivery of fifteen versions named Final_v3_approved_REAL_FINAL2.mp4, final-final.mov, Untitled.mp4 is a delivery that in six months no one will know how to use.

A reasonable naming convention includes, in order: brand, campaign, piece, version, language, format, resolution, date. For example: polimake-launch-spot-30s-en-mp4-1080p-2026-05-05.mp4. It's ugly to read but filterable, sortable, and understandable months later.

The detail becomes critical when there are multiple versions per channel: 30s/15s/6s, horizontal/vertical/square, with subtitles/without subtitles. A single piece can generate fifteen legitimate files. Without naming conventions, they're impossible to manage.

Mistakes that invalidate deliveries

Asking for "the final file" without specifying. Without defining master, intermediate, or delivery, the producer guesses. Guessing correctly 50% of the time is still 50% of deliveries done wrong.

Recompressing already-compressed deliveries. Taking an MP4 H.264 that YouTube compressed and re-exporting it to MP4 H.264 accumulates artifacts. Each generation loses quality. If you have to re-edit, go to the master, not the file downloaded from the channel.

Confusing compression with quality. "It's small, so it must be bad" isn't always true: H.265 at 8 Mbps can look better than H.264 at 12 Mbps. "It's big, so it must be good" isn't either: a badly rendered master can weigh 10 GB and look worse than a well-made 100 MB MP4.

Uploading 4K to destinations that only serve 1080p. Some channels recompress 4K to 1080p more aggressively than a 1080p already optimized by the producer. For Instagram, TikTok, and the like in 2026, uploading directly at the feed's native size produces better results than uploading 4K and letting the platform decide.

Not logging mastering loudness. A spot mixed at -10 LUFS sounds huge on social media but will be rejected by broadcast (which requires -23). One mixed at -23 will sound anemic on Instagram. You have to mix and export per-channel versions, or at least two masters with different loudness.

Forgetting the clean version. The "clean version" is the piece without final graphics, without burned-in subtitles, without overlaid text —just image and voice. It's the base on which future versions are built (other languages, other markets, other durations). Whoever doesn't request it in the original delivery has to renegotiate three months later.

How it fits into the workflow

Requesting formats correctly isn't just technical precision. It's what allows the piece to survive its first cycle of use. Delivery is the last phase of the video production process, but format decisions are anticipated from the shoot onward. A well-made delivery includes, at minimum:

• An archivable master (ProRes/DNxHR).
• A clean version without final graphics.
• A final per-channel delivery with codec and bitrate tuned.
• Subtitles in a separate SRT.
• A burned-in version for silent-consumption channels.
• A coherent naming convention.

This multiplies the files but divides the problems. The alternative —delivering only "the final"— produces immediate savings and medium-term pain.

Creative operations is the system that keeps this multiplicity from spiraling out of control. At Polimake, Studio defines which formats each production requests based on destination, Media executes the export and archives the masters, and Studio coordinates requests for future adaptations so they don't turn into urgent assignments.

This relates to the decision about bitrate per channel, the choice between MP4 and MOV in professional workflows, and when it's worth subtitling a video instead of burning in text.

To wrap up

"What format will the video be delivered in?" is really five questions: which container, which internal codec, which resolution and frame rate, which type of file (master, clean, final), and which versions per channel. Resolving all five before exporting prevents the delivery from turning into a negotiation that drags on for weeks.

The difference between a team that delivers well and one that doesn't isn't technical talent —both know how to export. It's discipline in requesting and discipline in archiving. Whoever has that discipline can recover an old piece, translate it, trim it, refresh it. Whoever doesn't, produces from scratch again every time something changes.

Quick references

• Master: ProRes 422 HQ or DNxHR HQ. Heavy but archivable.
• Generic digital delivery: MP4 H.264, AAC audio.
• Resolution: the channel's native one; never raise resolution artificially.
• Frame rate: the one from the shoot; don't convert.
• Color: Rec.709 for HD; Rec.2020 only if the destination accepts HDR.
• Subtitles: a separate SRT always, burned-in only for silent-consumption channels.
• Loudness: -23 LUFS broadcast, -14 LUFS streaming.
• Always a clean version: without final graphics, the base for future adaptations.
• Naming: brand-campaign-piece-version-language-format-resolution-date.
• Ask for multiple deliveries, not "the final."