If you are recording a typical SDR video in OBS and uploading that file to YouTube afterwards, use Partial output range and BT.709 as a compatibility-oriented starting point. That is an upload recommendation, not a universal setting for HDR, every master, or a live encoder.
Range and colour space describe different things. Set them with the file you are making in mind, keep the export metadata consistent with how it was mastered, then compare the local file with YouTube playback if the image changes.
First confirm the workflow: a file upload
This advice is for a prerecorded video: you create a file, then upload it to YouTube, or use that file as the source for a scheduled, always-on channel workflow. It is not a guide to configuring OBS while it sends a live signal directly to YouTube. The two workflows can share some colour standards, but their controls and points of failure are different.
For a straightforward SDR recording, start from the deliverable rather than from a setting copied from a live-streaming tutorial. YouTube’s upload guidance recommends BT.709 for SDR and says it converts full-range uploads to limited range. OBS documents Partial as its default video range. Together, those points make Partial and BT.709 a sensible baseline for an ordinary SDR upload, not a guarantee that every source or master should use them.
The useful question is not simply “should OBS be Full or Partial?” It is: what signal did the source produce, how did OBS interpret it, what did the output file contain, and what does YouTube do with that file? A capture card can interpret an incoming signal differently from the final file’s output range. Confusing those stages is one way a perfectly reasonable change in one control can make the video look worse.
If the video is part of a long-running channel, settle the file’s colour treatment before you put it into a repeating playlist. The practical issues around streaming regional-language videos to YouTube Live are different from colour metadata, but both reward a workflow in which the prepared asset is checked before it is asked to run unattended.
Range and colour space are separate controls
Colour range describes how brightness values are represented in a video signal. In common 8-bit video terminology, Partial, also called limited or legal range, uses a narrower nominal span of code values than Full range. Full uses a wider span. The important point is that these are alternative ways of representing levels; they do not describe whether the picture is SDR or HDR, or which colour primaries it uses.
Colour space is a separate choice. OBS’s Media I/O reference lists Rec. 601, Rec. 709, sRGB and Rec. 2100 PQ and HLG as distinct colour-space values, and separately lists Partial and Full video ranges. For a typical SDR YouTube upload, BT.709 is the platform’s recommended colour space. Selecting BT.709 does not itself set the range to Partial, and changing the range does not make a file BT.709.
A mismatch can produce symptoms such as washed-out-looking contrast or dark and bright details that seem clipped. Those symptoms are clues, not a diagnosis: a wrong range interpretation is one possibility, while a display or playback issue can also affect what you see. Avoid changing several settings at once because that makes it harder to tell which stage caused the change.
Keep these four stages distinct when tracing a problem:
| Stage | What to establish | Why it matters |
|---|---|---|
| Incoming source | What range the camera, computer, console or other device actually sends | A device’s signal is not automatically described by the final file setting |
| OBS source interpretation | Whether the source property decodes that incoming signal correctly | A capture source can need a different interpretation from the output file |
| Export | What range and colour-space information the encoder writes | The export should represent the intended master accurately |
| YouTube playback | Whether the processed upload looks different across playback devices | A display path can complicate comparisons |
OBS’s documented defaults and UI can vary in how they appear across versions or encoders. The reference is useful for understanding the meanings of the values, but it does not specify every hardware encoder’s file output or every interface path. For a non-technical workflow, note your OBS version and the exact export settings when you test, rather than assuming every menu behaves identically.
Choose Partial for the ordinary SDR export
For a typical SDR file being prepared for YouTube, leave the output range at Partial unless you have a specific reason to use something else and have verified the resulting file. Partial is OBS’s documented default. YouTube also says it converts a full-range upload to limited range, so choosing Full merely because it sounds like “more colour” is not a reliable way to improve an upload.
The word “Full” can sound like a quality setting, but it is not a general image-quality upgrade. It indicates a different range representation. If a signal encoded one way is decoded as the other, brightness levels may be remapped incorrectly. That is why a picture can appear flat, or why shadow and highlight detail may appear lost, even though the underlying footage has not changed.
In OBS, look for the output range setting associated with the recording or video configuration available in your version. If the choice is Default, OBS documents that as equivalent to Partial. Do not assume a source-specific property and the final output setting are interchangeable: one determines how OBS reads an incoming signal, while the other concerns the file being written.
There are valid exceptions. A capture device may send Full-range RGB, or a particular format and driver combination may use a range that needs explicit handling. A community guide from OBS forum contributor EposVox discusses such capture cases and the effects of mismatches. Treat it as practical troubleshooting, not a rule that overrides the current YouTube upload specification or proves what an untested device is sending.
If your source is a capture card, check the device’s own documentation and use a known image or chart to compare what comes in with what OBS records. Change the source interpretation only when evidence suggests OBS is reading the signal incorrectly. Do not force every input to Full because one preview looks different, or because the source happens to be RGB.
Set BT.709 for typical SDR
For standard SDR material, set the output colour space to BT.709, also commonly written Rec. 709. YouTube’s recommended upload encoding settings say BT.709 is the standard colour space it recommends for SDR uploads. This makes it a compatibility-oriented choice for the common case, rather than a claim that all video, all source material or all future workflows use the same standard.
Do not select an HDR colour space simply because it appears in OBS’s list. OBS identifies Rec. 2100 PQ and HLG separately from Rec. 709. Those options belong to different dynamic-range workflows. If your source and finished master are SDR, choosing an HDR option does not upgrade them; it risks making the setting inconsistent with what you actually created.
Likewise, do not infer that the word sRGB is interchangeable with BT.709 for every video export. The OBS reference lists those as separate values, and YouTube’s upload guidance names BT.709 for SDR. Follow the specification of the intended deliverable, rather than treating similarly familiar colour labels as synonyms.
A sensible sequence is to decide whether the content is SDR or HDR from the production workflow, choose a colour space that describes that master, then choose the range separately. If you have a standard SDR devotional video, lecture, lofi loop or local news package made for ordinary YouTube playback, BT.709 is the straightforward starting point. If you have a deliberately mastered HDR file, this SDR recommendation does not apply; use the relevant HDR guidance and verify the entire export path instead.
Match the metadata to the mastered file
A file’s metadata should describe the way the picture was mastered. A menu selection alone cannot correct an inaccurate master, and a correctly mastered image can still be misrepresented if the file tags describe something different. YouTube’s colour troubleshooting guidance identifies transfer characteristics, colour primaries and matrix coefficients as metadata that can cause colour problems when they do not match the mastering.
Think of metadata as the description attached to the picture, not a colour correction applied to it. If you exported an SDR BT.709 master, the relevant tags should not claim a different set of colour characteristics. If an editing application or encoder offers explicit colour tags, check that they agree with the project and master. Avoid using a tag change as a substitute for correcting a source-to-output mismatch.
If you record or render from OBS directly, retain a short test export before preparing a full set of channel files. Open it in a player or editor that can show file properties, if available, and inspect the colour information. The exact tools and labels differ, so the useful evidence is whether the encoded file’s stated properties agree with the intended SDR BT.709 master, not whether one application uses a particular menu name.
When an input device is involved, investigate its source interpretation separately. The camera or capture device may send a signal that OBS needs to decode in a particular way; the output file then needs settings and metadata appropriate to the finished master. A source range exception does not imply the finished upload should also use Full, just as a Partial output recommendation does not mean every incoming device signal is Partial.
For an image that looks wrong, write down the current source range, output range, colour space and export metadata before making a change. Then change one item, record a new short file and compare. This keeps the troubleshooting reproducible. A useful test image can reveal obvious clipping or level shifts, but it is not a replacement for checking the YouTube specification and the device’s actual behaviour.
Keep upload settings separate from live ingestion
A prerecorded upload has already been encoded as a file before YouTube processes it. Live ingestion instead receives an encoder’s outgoing signal in real time. YouTube’s live encoder settings also refer to Rec. 709 for SDR, but that does not make the live configuration the authority for a post-recording file export.
This distinction matters if your always-on channel uses prerecorded material. You may be uploading a finished file to YouTube as a video, or sending a file through a separate live-channel workflow. In the latter case, there is still an encoded live signal at the point of ingestion, but the original file’s preparation and the live encoder’s output are separate steps. Confirm which one you are configuring before following a guide.
If you use a repeating media source in OBS, there are additional questions about playlist behaviour, reconnects and the encoder’s live output. Those do not replace the need to prepare the source video correctly. For instance, a guide to keeping an OBS media source moving through a YouTube stream concerns playback continuity; it should not be read as a specification for colour metadata in a finished upload.
Similarly, a channel that sends a prerecorded loop through a continuously running process has different operational concerns from a simple file upload. The notes on running a YouTube radio stream with FFmpeg can help you think about a sustained broadcast pipeline, but its live encoding choices are not a substitute for matching the colour description of your source master.
If keeping a dedicated computer on for a prepared video loop is the recurring problem, StreamNeo removes that particular burden: you upload a file and provide your YouTube stream key, then the channel can continue without your own computer running. It does not change the need to prepare a suitable file or make the content eligible for any particular YouTube treatment.
Check the exported result before relying on it
First compare the export on your computer with the master or project preview you intended to create. Look at familiar scenes: dark hair or fabric, bright clouds or lamps, skin tones, and gradients. You are looking for a clear change in levels, crushed shadows, clipped highlights or an unexpected colour shift. A familiar still or short test segment is more useful than relying on a vague impression from a long loop.
Then upload a short private or unlisted test if you can, and compare the YouTube playback with the same local file. Make the comparison on the same display first, then try another browser or device if the result differs. YouTube’s troubleshooting guidance recommends checking the original and uploaded video in another browser or device, which helps distinguish file or processing behaviour from a playback-display issue.
Avoid judging a change while the upload is still processing or by comparing different screens with different display settings. Keep the original export unchanged so you can make a fair comparison. If the local export already looks wrong, troubleshoot OBS, the input interpretation or the encode before blaming YouTube. If the local file looks right but playback differs across devices, investigate the playback path and metadata before rebuilding the whole channel workflow.
For a 24/7 channel, quality control is worth doing before a file enters a playlist that will repeat overnight. A quick test will not prove every frame or every viewing device is perfect, but it can catch an obvious range mismatch before it becomes the version people keep seeing. Keep a known-good export and record the settings that produced it, especially if more than one person prepares files.
Do not buy a capture card, calibration product or chart just to resolve a general Full-versus-Partial question. The research needed is often a settings check and a repeatable local test. A capture device is relevant only when the source signal itself is being acquired incorrectly or you have a production need for that hardware; it is not a routine fix for a finished-file metadata problem.
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
Should OBS be set to Full or Partial for a YouTube upload?
For a typical SDR upload, use Partial as the compatibility-oriented starting point; OBS documents Partial as its default, and YouTube says it converts full-range uploads to limited range. Use a different setting only when you have a reason tied to the source or master and have checked the resulting file.
Is BT.709 the same setting as Partial?
No. BT.709 is a colour-space choice, while Partial describes the video range. For ordinary SDR YouTube uploads, BT.709 and Partial are a practical starting combination, but changing one does not set the other.
Why does my video look washed out on YouTube?
A range mismatch is one possible cause, but it is not the only one. Check the local export, its colour metadata and YouTube playback on another browser or device before changing several OBS controls at once.
Do these settings apply to HDR or a live encoder?
No. The recommendation here is for a typical SDR file uploaded after recording, not every master or HDR workflow. Live ingestion is a separate configuration process, even though YouTube also points to Rec. 709 for SDR live encoding.