If you want a smaller prerecorded video, export a smaller copy and inspect it before uploading; do not use YouTube Live encoder settings as a file-compression recipe. If your goal is a live broadcast, choose settings for the live feed instead: that is a different workflow, and the available YouTube guidance does not establish how a separate cloud archive is stored or compressed.
Start with the original file and decide which copy you need to make smaller. A lower resolution or bitrate can reduce the amount of data in an export, but the result depends on the source and your settings; there is no reliable fixed reduction to expect, and quality needs checking on your own footage.
First decide: upload file, live feed, or cloud archive
People often use “YouTube stream video” to mean three different things. You might be preparing a prerecorded file to upload, sending a live feed to YouTube, or keeping a separate copy in cloud storage. Work out which task you are doing before changing settings, because advice for one does not automatically apply to the others.
For an upload, you encode a file and submit it to YouTube. You can make a smaller copy by choosing a lower resolution, a lower bitrate, or both, then judge whether the result still suits the content. YouTube’s upload recommendations are a useful reference for export settings; they are not a promise that a particular file size will result or that a particular setting will look right for every source.
For a live broadcast, an encoder sends a continuing feed to YouTube. The live bitrate guidance covers that connection and its ingestion requirements. It is not a target for the size of a saved video file. A live bitrate may be relevant to what your connection must sustain while broadcasting, but it does not tell you how large an uploaded file or separate archive will be.
For an archive, first find out which copy is being kept and what controls it. If you keep the original, reducing a separate upload export does not necessarily reduce the archive. If you archive the smaller export, its size and quality reflect the settings used to make that copy. The research available for this subject does not establish how a separate cloud archive is stored, whether it is recompressed, or whether its behaviour changes with a platform or plan. Check the archive provider’s current documentation rather than assuming what happens behind the scenes.
This distinction matters for a 24/7 channel, too. A long prerecorded programme may be uploaded as a file, while a live channel sends an ongoing signal and may have a separate archive. If you want to prepare a 1080p playlist from larger source files, see this guide to downscaling 4K videos for a YouTube playlist stream. The same basic caution applies: make a deliberate copy for the intended use, rather than changing a live encoder because an upload file seems large.
What YouTube recommends for uploaded videos
For a normal prerecorded upload, YouTube Help recommends an MP4 container, H.264 video, progressive scan, variable bitrate, and keeping the recorded frame rate. Its upload encoding recommendations also describe settings such as High Profile, 4:2:0 chroma subsampling, Fast Start placement of the MP4 metadata, and BT.709 colour space for SDR video. These are platform recommendations for the submitted file, not a promise of an exact file size or a universal quality threshold.
Keep the source frame rate unless you have a specific reason to change it. YouTube’s examples include 24, 25, 30, 48, 50 and 60 frames per second, and its guidance says to encode and upload at the rate at which the content was recorded. Changing frame rate can affect motion; it is not simply a storage setting. If the original is 25 fps, exporting at 30 fps does not automatically make it better suited to upload.
Resolution and bitrate work together. Higher resolution retains more spatial detail and generally calls for more data at comparable encoding settings. YouTube publishes reference bitrates by resolution and frame-rate class for SDR and HDR, so use the table on its current page rather than carrying a number across to a different format or mode.
For SDR, YouTube lists 5 Mbps for 720p at 24, 25 or 30 fps and 7.5 Mbps for 720p at 48, 50 or 60 fps. For 1080p SDR, it lists 8 Mbps for the standard frame-rate class and 12 Mbps for the high frame-rate class. These are recommendations from YouTube Help, accessed in 2026; the page does not display a publication date in the retrieved material. They are reference points for upload encoding, not a claim that all footage at those settings has the same quality or that an export will reach a predictable size.
| Prerecorded SDR upload reference | Standard frame rates (24, 25, 30 fps) | High frame rates (48, 50, 60 fps) |
|---|---|---|
| 720p | 5 Mbps | 7.5 Mbps |
| 1080p | 8 Mbps | 12 Mbps |
If you are reducing a file, try the resolution that remains useful first, then make a short export at a suitable bitrate and inspect it. For a playlist of static devotional art or a lofi scene, a smaller frame may remain clear; small text, fine patterns, or quick motion can make the same change much more noticeable. The upload table gives a platform reference, but only a viewing check can tell you whether your own result is acceptable.
Do not add black bars or padding just to force a particular shape. YouTube says its player adapts to each video’s aspect ratio and device, and advises against adding padding to the video. See YouTube’s aspect-ratio and player guidance if the frame shape is part of your question. Correctly preserving the source’s aspect ratio is usually preferable to baking empty borders into every frame.
How live encoder settings differ
A live encoder sends a stream, so its settings are about a stable feed to YouTube, not about compressing a finished upload. YouTube’s separate live encoder settings and bitrate guidance lists RTMP or RTMPS ingestion, constant bitrate (CBR), and supported live codecs including H.264, H.265 (HEVC) and AV1. It also recommends a two-second keyframe frequency and says not to exceed four seconds. Check the current page before configuring your encoder, as its requirements and recommendations are the authority for the live workflow.
The live bitrate figures differ from the upload figures. For example, YouTube’s live table gives 14 Mbps for H.264 at 1080p30 and 10 Mbps for AV1 or H.265 at that resolution and frame rate; for 720p30 it lists 8 Mbps for H.264 and 6 Mbps for AV1 or H.265. These are YouTube Help recommendations accessed in 2026, not predicted sizes for a video file or a promise about an archive. Do not plug an upload recommendation into a live encoder, or read a live recommendation as the bitrate for a compressed upload.
The connection must be able to sustain the chosen live bitrate, including when other devices or work share the network. Run a speed test, select a quality the connection can support, and test with representative audio and movement before relying on the setup. A channel that appears still may still contain moving visualisers, scrolling text, or changing scenes. If you are diagnosing interruptions rather than trying to shrink a file, this guide to FFmpeg reconnect errors on YouTube Live addresses a different problem: keeping a live connection running.
For an always-on stream, check stream health during a test rather than judging by a brief preview alone. YouTube’s live guidance recommends monitoring the stream and testing representative content. If your connection cannot reliably sustain a setting, a lower live quality may be a more sensible trade-off than repeated drops. That decision affects the feed sent to YouTube; it does not by itself tell you how a separately saved source or archive is encoded.
Choose a compression approach for a copy
For a prerecorded file, begin with the best available original and create a separate export. Re-encoding an already compressed file can make defects more visible, so avoid repeatedly making a new copy from the last compressed copy when you can return to the original. This is cautious workflow advice, not a YouTube rule or a quantified guarantee about the result.
A straightforward export path is MP4 with H.264, progressive scan, variable bitrate and the source frame rate. These settings align with YouTube’s upload recommendations and are a sensible baseline for a normal upload. If a file is still too large for your purpose, consider reducing resolution, bitrate, or both, then inspect the copy. Do not assume a codec choice listed for live ingestion is also YouTube’s recommendation for an uploaded file.
A practical first change is often resolution when the source is larger than the audience needs. For instance, if a 4K recording is intended to be watched as a 1080p playlist, an export at 1080p may be a reasonable test. It will discard spatial detail compared with the 4K original, so keep that original if you may need it later. A separate 4K-to-1080p downscaling guide can help you think through that particular choice.
Bitrate is another lever, but lower is not automatically better. If you reduce it too far, moving edges, fine textures, gradients or text can become visibly rough or smeared. The right balance depends on the visual material and how it will be viewed. A local news loop with readable captions may need a different compromise from a mostly still ambience video.
Keep separate, clearly named files for the original, the upload export and any archive copy if those are different jobs. This makes it easier to know which version you are uploading or retaining, and to return to the higher-quality source if the first export does not look right. The name itself does not change compression; it prevents a workflow mistake.
Balance file size against visible quality
File size is affected by more than a single setting. Duration matters, as does bitrate; resolution and frame rate affect how much visual information an encoder must represent, while content complexity influences how demanding frames are. A slow-moving image and a fast, detailed scene can behave differently at the same nominal settings. No universal percentage saved can be inferred from YouTube’s recommendation tables.
| Change to consider | Likely trade-off | What to inspect |
|---|---|---|
| Lower resolution | Less spatial detail; smaller text and fine elements may be harder to read | Captions, logos, patterns and distant detail |
| Lower bitrate | Less data for the encoder to represent the image; artifacts may become more visible | Motion, gradients, foliage, textures and edges |
| Keep the recorded frame rate | Preserves the original timing; high-frame-rate footage has a higher YouTube reference bitrate category | Motion smoothness and any cadence changes |
| Retain a higher-quality original | Uses more storage for the source, but keeps a better starting point for future exports | Confirm which copy is being uploaded or archived |
Treat each change as a test, not a promise. Make a short export using a representative portion of the programme, then compare it with the source at the size and device your viewers are likely to use. A small text crawl can look acceptable on a computer monitor but become difficult to read on a phone. Similarly, a static image can hide compression problems that become obvious once a camera pan or animation begins.
If the video is SDR, preserve accurate colour metadata and use BT.709 as the recommended colour space described by YouTube. A bitrate reduction cannot correct a wrong colour space or repair a source with incorrect colour information. Check colour and brightness as well as sharpness, especially in gradients such as a sky, a lamp glow or a dark background where banding can be conspicuous.
For 24/7 playback, repeated visual material can tempt you to choose the smallest export that plays once without obvious defects. Consider the whole programme: text needs to remain legible, motion should not break up, and audio should remain clear. If an export is barely acceptable on your editing screen, it may be less comfortable on a viewer’s phone or television. Choose a conservative setting when the channel’s purpose depends on detail, then keep the original as a fallback.
Inspect the result before uploading
Do not commit a long programme to a setting based only on the export dialog. Make a short representative sample first. Include the hardest parts of the video: fast movement, fine detail, small text, gradients, dark scenes and any transitions. This sample-checking method is practical advice; YouTube’s official upload pages do not prescribe a particular sample duration or a pass/fail test.
Compare the sample with the source under similar viewing conditions. Look for blocky edges, smearing when objects move, broken fine lines, banding in smooth colour changes, or text that has become hard to read. Listen as well as look: verify that the export still contains the expected audio and that dialogue, devotional singing or ambient sound remains clear. If one section fails, adjust the export and test again rather than assuming the whole programme will be fine because its still frames look acceptable.
Check basic file details before upload: resolution, frame rate, format, and whether the exported duration and audio match the intended programme. Play the file from beginning to end if it is short, or check representative sections at the start, middle and end if it is long. A wrong trim or missing audio track is not solved by a lower bitrate.
Avoid making several generations of compressed copies while experimenting. Return to the original for each test so that you can compare the actual setting change rather than the accumulated effect of prior exports. Keep the source until you have reviewed the uploaded version and decided what your archive should contain. Storage decisions for a separate cloud archive depend on its own workflow; the YouTube upload settings do not establish what that archive retains.
What YouTube transcodes after live ingest
The stream you send and the formats viewers receive are not necessarily the same thing. YouTube says it automatically transcodes live streams into multiple output formats so viewers on different devices and networks can watch. This means live ingest settings describe what you send to the platform, while playback is prepared for viewing conditions; the live bitrate table should not be mistaken for an archive-size calculator.
Transcoding for playback also does not tell you how a separate cloud copy is stored. The official guidance cited here covers YouTube uploads, live ingestion, and live playback formats. It does not document the behaviour of an independently maintained archive, nor establish whether such a copy is compressed, kept in its original form, or retained at a particular quality. If that storage outcome matters, consult the provider that holds the archive and identify which file you are supplying to it.
For a live channel, test the broadcast path and archive path separately. Confirm the outgoing stream is stable at your chosen live settings; then confirm what file, if any, is actually being saved elsewhere and how you can verify it. If your real concern is a growing YouTube radio archive rather than the size of a source file, see how to keep a YouTube radio livestream archive from becoming too long. It deals with archive length, a related but distinct issue from compressing an upload copy.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does lowering the upload bitrate guarantee a smaller file?
A lower bitrate generally means less data for the encoder to represent, but the final size depends on the export, duration and encoding choices. YouTube’s recommendations do not promise a fixed reduction. Export a short sample and check the actual file and visible quality before processing the full programme.
Can I use YouTube’s upload bitrate as my live bitrate?
No. YouTube publishes separate guidance for prerecorded uploads and live ingestion, and the tables differ. Use the live settings for the feed you send during a broadcast, and the upload recommendations when preparing a file for upload.
Will compressing my upload also shrink a separate cloud archive?
Not necessarily. That depends on which copy the archive keeps and on the archive provider’s process; the YouTube guidance discussed here does not establish separate archive behaviour. Check the provider’s current documentation and confirm which version of the file is being retained.
Should I delete the original after exporting a smaller copy?
Keep it until you have checked the export and are sure it serves its purpose. The original gives you a better starting point if you need another resolution or bitrate later. If storage is limited, decide separately which copy is needed for upload and which one you want to retain as an archive.