An HTTP 403 from FFmpeg tells you that a request was refused; by itself, it does not identify the reason. Start in YouTube Studio: copy the current stream key, confirm the ingest URL for the intended stream, and check that the correct broadcast is selected.
If you use a scheduled broadcast, wait for its preview before choosing Go live. If you chose RTMPS, use the RTMPS URL shown in Studio and confirm that your FFmpeg build supports that transport. These checks narrow the problem without treating one status code as a complete diagnosis.
What a YouTube RTMP 403 does not prove
A 403 is a symptom, not a verdict that the key is wrong. YouTube’s public troubleshooting pages discuss startup errors, stream keys, server URLs, connection timeouts and SSL errors, but do not define every HTTP 403 as having one cause. The useful response is to test the settings and state that YouTube can verify, then use the encoder and Live Control Room messages to decide what to investigate next.
A stale or mismatched key is a sensible early hypothesis because the encoder needs a key YouTube recognises for the intended stream. But the endpoint could also be wrong, the protocol may not match the URL, or the broadcast selection may not be the one you expect. Those possibilities are distinct; changing settings at random can make it harder to tell which one mattered.
Treat the exact FFmpeg output as evidence, not as a complete explanation. Note the selected URL, the point at which the connection fails, and whether Studio reports an incoming feed. Do not share a stream key when asking for help: it is a credential, and a log or screenshot that exposes it can let someone else use the stream.
YouTube describes keys as “like your YouTube stream’s password and address” in its stream settings guidance. That is a useful way to think about them: protect the key, and make sure it belongs to the broadcast you mean to send. If you cannot establish which setting is wrong, keep the error message and redact credentials before sharing it with a trusted administrator or support channel.
Copy the current stream key from Studio
Open YouTube Studio and go to Live Control Room, then select the stream or its Stream settings. Copy the key currently displayed for the intended stream and update the value FFmpeg receives. YouTube’s guidance for third-party encoder startup errors recommends obtaining a key from Live Control Room and updating the encoder. That makes this a better first check than relying on an old command, saved note, or configuration copied from another channel.
Check where FFmpeg obtains the key. It may be supplied directly in an address, through a configuration file, or from an environment variable in a script. Follow the path used by your own setup and check that the value has not been truncated, surrounded by accidental characters, or replaced by a key for another stream. Do not paste the real key into a public command example or diagnostic report; redact it before sharing.
If you suspect the key has been exposed or the saved value cannot be trusted, reset it in Studio and replace it everywhere your encoder uses it. YouTube notes that resetting a key is restricted to channel owners and managers; an editor or viewer may be able to see other settings without having permission to reset the credential. After a reset, an encoder still using the old key will not become correct by retrying, so update the actual source of the value.
For a channel that runs several kinds of content, label local configuration by channel and broadcast purpose rather than keeping several unexplained keys together. A devotional loop, a local news feed and a study stream can each have separate saved settings. The label is not proof that the key is right, but it reduces the chance of sending one stream’s credential with another stream’s media.
Verify the stream-specific ingest URL
The stream key is only part of the destination. Compare the server or ingest URL in FFmpeg with the URL shown for the intended stream in Live Control Room. YouTube’s encoder setup instructions ask you to provide both a server URL and a stream key. A correct key paired with the wrong server address is still a mismatched configuration.
Check the full value, not just its opening letters. A URL copied from a different stream, a clipped field, an extra quote introduced by a script, or an old saved command can all leave FFmpeg sending to a destination other than the one Studio shows. Compare the configured URL character by character with the current value in Studio, while keeping the key private. Do not assume that a familiar-looking address is the right endpoint for every stream.
Also check how your command assembles the destination. Some configurations keep the server URL and key in separate fields; others combine values in a way that depends on the encoder invocation. The official setup guidance describes the server URL and key but does not provide a universal FFmpeg command for every shell, build or workflow. Avoid copying a command from an unrelated setup and treating it as a guaranteed fix. Instead, verify what value FFmpeg actually passes and compare it with Studio.
If your channel has more than one stream configured, open the one you intend to run before copying either value. A useful local record can identify the channel, stream purpose, protocol and date you last checked the settings, without storing an exposed credential in plain text. The goal is not to make the configuration elaborate; it is to distinguish the intended destination from a leftover one.
Check the intended stream or scheduled broadcast
In Live Control Room, confirm that the broadcast you expect to use exists and is selected. If you schedule events, check the title and time rather than assuming that the next event in a list is the correct destination. The ingest settings and broadcast context should agree with the content you are sending.
For a scheduled stream, YouTube’s setup flow is to connect the encoder, wait until the stream preview appears, and then choose Go live. Do not treat the encoder’s attempt to connect as proof that the intended broadcast is ready. If the preview appears under a different event, stop and select the right one before going live; otherwise, you may be diagnosing a broadcast selection problem as if it were an FFmpeg transport fault.
There is a separate account-eligibility check. YouTube’s live-streaming tips say that a channel needs verification and must not have live-streaming restrictions during the preceding 90 days to stream. If the channel cannot access live streaming or Studio shows a restriction, resolve that with YouTube’s current account guidance. An eligibility issue is not the same thing as an endpoint mismatch, and changing an FFmpeg URL will not address it.
If the stream is part of a continuous channel, decide in advance whether a new event or an existing stream is intended. A recurring file-based channel may need a predictable broadcast workflow, while a one-off scheduled programme has a defined event and start time. For a broader look at continuity choices, see how to set up an always-on YouTube stream. The immediate check remains in Studio: confirm the broadcast you mean to use, then connect to its displayed settings.
Wait for the preview before going live
A preview is a practical checkpoint between FFmpeg sending a feed and the audience seeing a live broadcast. Once the key and URL are in place, look at Live Control Room for an incoming preview. If it does not appear, note whether FFmpeg reports a connection rejection, timeout, or another error, and whether Studio shows any feed or health information. That difference helps separate a connection problem from a broadcast that is connected but not yet live.
Do not click Go live merely because FFmpeg has begun outputting data. First make sure the preview shows the intended picture and sound, and that it is attached to the intended broadcast. For a static visual with music, for example, check that the expected loop is visible and that audio is present before making the scheduled event public. This catches wrong-file or wrong-event mistakes that a successful connection alone cannot catch.
If a preview is absent, return to the earlier checks in order: current key, matching server URL, selected stream and chosen protocol. Avoid changing several values at once. Change one verified item, reconnect, and see whether Studio’s display changes. That gives you a useful record of what you tested rather than a pile of edits with no clear result.
For a file-based music channel, the encoder’s job may include repeating a playlist, while YouTube’s broadcast workflow still needs a valid feed and the correct event. These are separate jobs. The article on running a 24/7 music radio stream with VLC playlist repeat covers the playlist side; it does not replace checking the current stream’s key, URL and preview in Studio.
If using RTMPS, confirm the URL and encoder support
RTMP and RTMPS are related ingest protocols, but their URLs are not interchangeable. YouTube recommends RTMPS for encrypted ingestion. If you select RTMPS, use the RTMPS URL revealed in Live Control Room and confirm your FFmpeg build and invocation can use RTMPS. Do not take an RTMP URL and assume that changing a few letters, or choosing a different port, makes it the correct secure endpoint.
YouTube’s RTMPS guidance says to use rtmps for both the protocol and server when configuring that option. Follow the URL Studio provides for your stream rather than deriving one from memory. Check your local FFmpeg documentation or build details to confirm support for the selected transport; a command that works with one protocol does not establish that the same build accepts the other.
The RTMPS help page discusses port 443 in the context of certain SSL errors. That is not a universal repair for HTTP 403, so do not switch ports on that basis alone. Likewise, an SSL error or connection timeout is a different clue from a clean server refusal. Keep the actual FFmpeg message and Studio status in view rather than labelling every failed attempt “the 403 problem”.
If you are unsure which protocol you selected, return to Studio and read the complete server URL. Then configure FFmpeg to use that exact destination and retest. If you choose ordinary RTMP instead, use the RTMP URL shown for the stream. The decision is about matching the selected endpoint and supported transport, not about treating one protocol as an interchangeable spelling of the other.
Retest and review Live Control Room health
After a change, reconnect and review both sides: FFmpeg’s latest output and Live Control Room’s stream status or health display. A connection that reaches Studio but has poor or missing media is a different problem from a request refused before a feed appears. YouTube’s live-stream troubleshooting guidance recommends checking the encoder, the local feed and the outbound connection when diagnosing streaming problems. Those checks help when the symptom extends beyond a simple refusal; they do not prove what a particular 403 means.
If Studio shows a feed, inspect the video and audio before choosing Go live. If FFmpeg reports repeated connection errors and Studio shows no feed, revisit the key, URL and transport, then check that the encoder is using the values you just updated. If the values match and the failure persists, preserve the exact error text and time of the test, with credentials removed, for further diagnosis.
A local test can also distinguish a broken source from a rejected ingest. Check that the file or playlist plays on the machine running FFmpeg, and that the encoder is not reporting an unrelated input or resource error. If the local output is healthy but the connection is not, follow the endpoint and network clues. YouTube’s documentation treats timeouts, SSL problems and encoder health as separate checks; avoid collapsing them into a claim that the key must be at fault.
For ongoing operations, write down the known-good non-secret settings and the steps needed to reconnect. If the stream is meant to run overnight, a plan for restarting and monitoring matters as much as the first successful test. This guide to keeping a study music stream live without a home computer discusses the continuity question separately from this error diagnosis. Where FFmpeg runs, how it is monitored and who can recover it are operational choices; none changes the need to confirm the correct YouTube key and endpoint.
If repeatedly managing a local machine through the night is the specific pain, StreamNeo removes that computer-running burden for a file-based YouTube broadcast: you upload the video once, connect the channel’s stream key, and can leave your own computer switched off while the stream is monitored and restarted if it drops. It is YouTube-only, and it does not determine whether your content or channel meets YouTube’s requirements; check Studio and the current official guidance for those.
When you have verified the settings and are choosing how to operate the stream, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
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 a YouTube RTMP 403 always mean my stream key is invalid?
No. A stale or mismatched key is worth checking early, but YouTube’s public guidance does not define every HTTP 403 as a single-cause error. Compare the current key and server URL in Studio, then check the selected broadcast and the exact encoder message.
Should I replace RTMP with RTMPS to fix a 403?
Not as an automatic fix. YouTube recommends RTMPS for encrypted ingestion, but you must use the RTMPS URL shown in Studio and an encoder build that supports it; RTMP and RTMPS URLs are not interchangeable. Make the protocol choice deliberately and retest against the matching endpoint.
When should I click Go live on a scheduled stream?
Wait until the stream preview appears in Live Control Room, then confirm that it shows the intended content and belongs to the scheduled broadcast you mean to use. Select Go live only after those checks. A connected encoder alone is not confirmation that the right event is ready.
What should I share when asking for help with FFmpeg?
Share the exact error text, the protocol and whether Studio shows a preview or feed, but redact the stream key and any URL component that exposes it. Include how you verified the endpoint and whether the broadcast is scheduled. Do not publish credentials in logs, screenshots or public issue reports.