How to Configure Encoding Presets for YouTube and Vimeo

Start with two presets, not one: a high-quality H.264 MP4 preset for YouTube, and a Vimeo preset that can be either H.264 MP4 or a mezzanine-style upload like ProRes 422 HQ when upload time allows. Both platforms will transcode your file after upload, so focus on sending them a clean, progressive, correctly framed master with enough bitrate that their first transcode is working from good material instead of trying to “match” their playback encodes. That distinction matters because a YouTube or Vimeo upload isn't the same thing as a client approval proxy, an archive master, or a broadcast deliverable. It's an input to a platform encoder. If you over-compress it, scale it badly, export it with variable frame rate, or bake black bars into the frame, the platform will faithfully transcode those problems into every playback version it generates.

A high-quality upload acts as the source file for the platform’s own playback encodes.

The preset decision that actually matters

For most post teams, the decision tree is simple. H.264 in an MP4 container is the safest upload preset when you need broad compatibility across YouTube, Vimeo, clients, producers, and review workflows. H.265 is useful when file size is a real constraint and your encoding system can produce a clean HEVC file without slowing the room down. ProRes 422 HQ is a good Vimeo option when the project benefits from a higher-quality mezzanine upload and the team can tolerate the larger file and longer transfer. YouTube’s own upload guidance centers on H.264 in an MP4 container. Vimeo accepts most major codecs, but explicitly recommends H.264, H.265, and Apple ProRes 422 HQ for best results. That means the default presets shouldn't be exotic. Your team should make them boring, repeatable presets that the next assistant editor can identify in the export queue. A good delivery preset library usually has these variants:

YouTube 1080p H.264 MP4
YouTube UHD H.264 MP4
Vimeo 1080p H.264 MP4
Vimeo UHD H.264 MP4
Vimeo ProRes 422 HQ upload
Optional H.265 versions for longform or bandwidth-constrained uploads

The takeaway is that “YouTube/Vimeo preset” is too vague. Your team should name presets by platform, resolution, codec, and purpose. If someone sees Vimeo_UHD_ProRes422HQ_Upload, they know it isn't the same output as Vimeo_UHD_H264_ClientPreview.

Preset	Container	Video codec	Best use	Main tradeoff
YouTube H.264 upload	MP4	H.264 High Profile	Routine YouTube uploads and broad playback compatibility	Larger than HEVC at similar visual quality
Vimeo H.264 upload	MP4	H.264 High Profile	Default Vimeo uploads, client-friendly files, and normal turnaround	Less robust than ProRes for gradients, grain, and heavy texture
Vimeo H.265 upload	MP4	H.265/HEVC	UHD or longform uploads where transfer size matters	Slower encoding and less reliable local playback on older systems
Vimeo ProRes 422 HQ upload	MOV	Apple ProRes 422 HQ	High-value Vimeo uploads when source quality matters more than file size	Much larger files and longer uploads

Build from the timeline, not from the platform player

Your export should start from the finished sequence settings and the actual delivery intent. Match the final timeline resolution, frame rate, aspect ratio, field order, and color space unless there's a clear reason not to. For most SDR web delivery, the baseline should look like this:

Progressive scan
Square pixels
Constant frame rate
Native timeline frame rate
Native timeline aspect ratio
Rec.709 for standard SDR work
AAC audio at 48 kHz for compressed MP4 delivery

Don't export interlaced files for these platforms unless you have a very specific legacy reason and know exactly how the platform will handle it. YouTube explicitly recommends progressive scan. Vimeo recommends maintaining the native frame rate, using constant frame rate, and avoiding variable frame rate. Vimeo also notes that footage above 60 fps may be reduced automatically. If you're cutting from camera originals through proxies, don't export the upload from the proxy media by accident. This sounds obvious until a team is late, someone has proxies attached, and the export looks “fine” in a small review player. In offline workflows, your finishing workflow should relink or conform back to the high-resolution source or finished master before encoding. Proxy workflows depend on clip names, reel names, and source timecode staying consistent, because the online handoff breaks when those identifiers drift.

YouTube upload preset settings

YouTube’s recommended upload settings are specific enough to turn into a clean preset. The normal choice is H.264 video in an MP4 container with AAC-LC audio. Use these settings as the base for a YouTube H.264 preset:

Container: MP4
Video codec: H.264
Profile: High
Scan type: Progressive
Entropy coding: CABAC
B-frames: 2 consecutive B-frames
GOP: Closed GOP, about half the frame rate
Bitrate mode: Variable bitrate
Audio codec: AAC-LC
Audio sample rate: 48 kHz
Audio channels: Stereo, or stereo plus supported surround where needed
Fast Start: moov atom at the front of the file
Edit lists: Avoid edit lists

The “Fast Start” setting matters because it places the MP4 metadata where the platform can process the file efficiently. YouTube also warns against edit lists because they can cause processing problems. In most NLE export panels, you won't see every one of these labels in the same language, but you can usually control the important pieces: MP4, H.264 High Profile, progressive, VBR, AAC, and fast-start/web-optimized output. For bitrate, YouTube says there's no required bitrate limit, but it publishes recommended reference rates. For SDR uploads, common targets are roughly:

720p at 24, 25, or 30 fps: around 5 Mbps
1080p at 24, 25, or 30 fps: around 8 Mbps
1440p at 24, 25, or 30 fps: around 16 Mbps
2160p at 24, 25, or 30 fps: around 35 to 45 Mbps
720p at 48, 50, or 60 fps: around 7.5 Mbps
1080p at 48, 50, or 60 fps: around 12 Mbps
1440p at 48, 50, or 60 fps: around 24 Mbps
2160p at 48, 50, or 60 fps: around 53 to 68 Mbps

Those numbers are platform reference points. If you have noisy concert footage, dense particles, fast camera moves, water, confetti, film grain, or dark gradients, you can push above the reference bitrate to help preserve the file before YouTube transcodes it. If the piece is a locked-off interview on a clean background, the reference bitrate may be plenty. Avoid exporting a tiny file because “YouTube is going to compress it anyway.” That logic is backwards because YouTube will make its own playback encodes no matter what. Your job is to make sure the platform isn't starting from macroblocking, banding, mosquito noise, and softened edges.

Vimeo upload preset settings

Vimeo gives teams a little more room in the upload file. Its compression guidance recommends H.264, H.265, and ProRes 422 HQ, and Vimeo’s OTT guidance lists a 250 GB file size limit. For normal upload workflows, H.264 MP4 is still the best default. For high-value masters, screenings, portfolio work, and pieces where gradients or texture matter, ProRes 422 HQ can be worth the larger file. A solid Vimeo H.264 MP4 preset should use:

Container: MP4
Video codec: H.264
Profile: High where available
Scan type: Progressive
Frame rate: Native and constant
Resolution: Match the finished sequence
Pixel aspect ratio: Square pixels
Bitrate mode: VBR
Audio codec: AAC
Audio sample rate: 48 kHz

Vimeo’s own Premiere guidance starts from H.264 with a custom preset and match-sequence style settings. The custom preset should preserve the finished timeline correctly and avoid unnecessary conversion, regardless of the brand name of the preset in Adobe Media Encoder, Compressor, Resolve, or HandBrake. For a Vimeo ProRes upload preset, use it as a mezzanine-style handoff:

Container: MOV
Video codec: Apple ProRes 422 HQ
Resolution: Match the finished sequence
Frame rate: Native and constant
Scan type: Progressive
Audio: Uncompressed PCM or high-quality audio settings from the finishing app

A ProRes 422 HQ upload can be many times larger than an H.264 or H.265 upload, so the transfer window matters. For a 60-second brand film, that may be trivial. For a 90-minute program on a deadline, it may be the wrong move unless the pipeline has the bandwidth for it. Use file-size and upload-time estimates before promising a delivery window.

Where H.265 fits

H.265, also called HEVC, can deliver similar visual quality to H.264 at a smaller file size, especially at UHD resolutions. Vimeo recommends H.265 as one of its preferred codecs. YouTube accepts HEVC uploads in many workflows, but its published recommendation still points editors toward H.264 MP4. The tradeoff is time and compatibility because H.265 can be slower to encode, slower to QC on older machines, and more annoying in approval workflows if a stakeholder downloads the file and tries to play it locally. Hardware encoding helps, but hardware encoders vary in quality. A fast HEVC export from one workstation may not look as good as a slower software encode or a higher-bitrate H.264 export from another. H.265 makes sense when the constraint is transfer size, not when the constraint is simplicity. A good rule for teams is:

H.264 MP4 for routine YouTube and Vimeo uploads
H.265 MP4 for UHD uploads where bandwidth or storage is tight
ProRes 422 HQ for Vimeo when upload quality matters more than transfer size
A separate ProRes or DNxHR master for archive, not as a replacement for platform-specific uploads

That keeps HEVC in the toolkit without making it the default answer for every export.

Aspect ratio and resolution choices

Don't force every export into 16:9 just because the platform player is often 16:9. Export the actual finished frame.

Export vertical work as a native vertical frame instead of trapping it inside a horizontal raster.

If the piece is 3840x2160, export 3840x2160. If it's 1920x1080, export 1920x1080. If it's 1080x1920 for vertical delivery, export 1080x1920. If it's a 2.39:1 timeline, export the actual active raster if your workflow supports it, or make a deliberate container decision with the finishing team. What you want to avoid is accidental letterboxing or pillarboxing baked into a file that the platform then places inside its own player framing. Common framing mistakes include:

Exporting a vertical sequence inside a horizontal 16:9 frame
Adding black bars in the edit instead of using the correct sequence raster
Scaling UHD media down to HD, then upscaling it back to UHD for upload
Misinterpreting pixel aspect ratio on legacy or broadcast-derived media
Cropping captions, lower thirds, or graphics because the export preset used the wrong dimensions

The cleanest preset is usually “match source” for dimensions and frame rate, with deliberate overrides only for known deliverables. If the timeline is UHD but the delivery must be HD, downscale once at export using a high-quality scaler. Don't make an HD intermediate, reimport it, add titles, and then export again. Every extra generation gives the platform encoder less to work with.

Bitrate is content-dependent

Bitrate recommendations are useful starting points, but the content decides whether they're enough. Compression has a much easier time with clean interviews than with handheld night exteriors, smoke, rain, grain, fast cuts, screen recordings with tiny text, or animated gradients.

Bitrate needs rise when the picture has more motion, grain, detail, or compression stress.

When a scene is hard to compress, artifacts usually show up as:

Banding in skies, walls, shadows, or gradients
Blockiness in dark areas
Smearing in fast motion
Crawling noise around titles or fine patterns
Softened texture in skin, fabric, foliage, or grain

If the uploaded file already shows these issues, the platform transcode will usually make them worse. Increase the upload bitrate, use a better encoder mode, export from a higher-quality source, or choose a mezzanine upload where the platform supports it. For H.264, two-pass VBR can help when your schedule allows the encode time. For short high-value pieces, the extra encode time is often worth it. For high-volume social cuts, a well-tested one-pass hardware preset may be the better operational compromise, as long as your QC pass confirms it holds up.

Avoid generation loss

The best way to re-encode a file is to export again from the project or finishing application, not to transcode a compressed approval copy into another compressed upload. Vimeo says this directly in its guidance, and it matches normal post-production practice.

Export from the project or master timeline instead of chaining compressed files together.

Bad upload chains look like this:

Camera original to proxy
Proxy to review MP4
Review MP4 downloaded from a platform
Downloaded MP4 re-exported for YouTube or Vimeo
Platform transcodes again

Each step throws away information, so by the time the public platform creates its playback versions, it may be working from the third or fourth compressed generation. A better chain is:

Camera originals or high-quality intermediates into edit
Conform or relink for finishing
Export a high-quality master
Encode platform upload from the master or directly from the finishing timeline
Keep the platform upload file with the delivery record

That last point matters for teams, so store the exact upload file next to the master, captions, thumbnails, audio stems, and approval notes. If someone asks why Vimeo looks different from YouTube, you need to know whether they came from the same master, the same grade, and the same export generation.

Audio settings that don't cause surprises

Audio is usually less mysterious than video, but it still causes delivery problems, so use 48 kHz audio for both platforms. For MP4 exports, AAC-LC is the safe default. YouTube supports AAC-LC, Opus, and newer immersive options in certain workflows, but AAC-LC is still the normal web video delivery choice. For stereo web uploads, keep it simple:

Codec: AAC-LC
Sample rate: 48 kHz
Channels: Stereo
Bitrate: 320 kbps when available, or another high-quality AAC setting

If you're delivering surround, make a specific surround preset and label it clearly. Don't let a stereo preset accidentally fold down a 5.1 mix without review. Also avoid sample-rate conversion late in the chain if the mixer delivered the mix at 48 kHz, which is standard for video post.

How to test the preset once

Test the preset on material that's hard enough to expose problems. Use a short test timeline with the kinds of shots your team actually delivers:

A dark scene with gradients or shadow detail
Fast motion or handheld camera movement
Fine texture such as hair, fabric, foliage, or grain
Graphics, subtitles, and lower thirds
A shot with saturated color
A typical dialogue section with final mix audio

Export with the preset, watch the file locally, upload it privately or unlisted, then compare the platform playback after transcoding finishes. Don't judge only the first low-resolution processing pass. Platforms often make an initial version available before all higher-quality encodes are ready. If the local export is clean but the platform playback falls apart, raise the upload bitrate or try a higher-quality source format. If the local export already has artifacts, the problem is your encode, not the platform.

Naming and maintaining presets

Preset names should remove ambiguity, so include platform, raster, frame rate only when needed, codec, and purpose. For example:

YouTube_1080p_H264_Upload
YouTube_UHD_H264_Upload
Vimeo_UHD_HEVC_Upload
Vimeo_UHD_ProRes422HQ_Upload
Archive_UHD_ProRes422HQ_Master

Don't hide meaningful differences behind “Final,” “Final_v2,” or “Web Export.” Those names travel badly across teams because an editor, AE, post supervisor, or TD should be able to open the folder six months later and understand what the team uploaded, what the team archived, and what was only for review. When platform guidance changes, update the preset and version the name or maintain a short delivery note. The preset is part of the workflow, not a personal preference buried on one workstation.

The clean export wins

YouTube and Vimeo are going to transcode your upload, but you can control the quality, structure, and correctness of the file you hand them. For YouTube, default to H.264 MP4 with progressive video, High Profile, VBR, AAC-LC audio, 48 kHz audio, Fast Start, and no edit-list weirdness. For Vimeo, default to H.264 MP4 for normal work, consider H.265 when file size matters, and use ProRes 422 HQ when the upload can justify the larger mezzanine file. Most visible problems come from the boring stuff: wrong raster, baked-in bars, variable frame rate, low bitrate, proxy exports, repeated transcoding, or a preset inherited from a totally different deliverable. Build a small preset library, test it on difficult material, and keep the upload file tied to the project record. That gives the platform encoder the best possible starting point and gives your team fewer mysteries to chase after delivery.

FAQ

H.264 in an MP4 container is the safest default for both platforms because it's widely supported, easy to review, and aligns with YouTube’s recommended upload guidance. H.265 can be useful for UHD files when upload size is a constraint, but it may take longer to encode and can create playback or QC issues on older systems. Vimeo also supports ProRes 422 HQ for higher-quality uploads when file size and transfer time are acceptable.

ProRes 422 HQ can give Vimeo a cleaner source file to transcode, especially for high-value work with gradients, texture, grain, or heavy motion. The tradeoff is much larger file size and longer upload time. For routine web delivery, H.264 MP4 is usually the practical default. For portfolio pieces, screenings, and premium client work, ProRes 422 HQ may be worth using if the schedule supports it.

Use YouTube’s published recommendations as a starting point, not as a strict ceiling. For SDR video, common targets include about 8 Mbps for 1080p at 24 to 30 fps, about 12 Mbps for 1080p at 48 to 60 fps, about 35 to 45 Mbps for UHD at 24 to 30 fps, and about 53 to 68 Mbps for UHD at 48 to 60 fps. Noisy, fast-moving, dark, or highly detailed material often benefits from higher upload bitrates.

A compressed review file has already lost image information. If it's downloaded, re-exported, and then uploaded to YouTube or Vimeo, the platform transcode starts from a degraded source. That can increase banding, blockiness, smearing, and soft edges. The better workflow is to encode the platform upload from the finishing timeline, a conformed project, or a high-quality master.

In most cases, no. Export the finished frame at its intended dimensions instead of baking black bars into a 16:9 file. Baked-in letterboxing or pillarboxing can cause the platform player to display the video inside additional framing, especially on phones, embedded players, or non-standard layouts. Use the correct sequence raster and scale only when there's a deliberate delivery requirement.

Export a short stress test, upload it privately or unlisted, then compare the local file and the platform playback after processing finishes. Frame-specific notes are important because compression problems often appear in one gradient, title, or fast-motion shot. Aspect supports frame-accurate comments and annotations in the review workflow.