An RTMP destination is the receiving endpoint your encoder sends a live broadcast to. Its server URL points to the platform’s ingest service, while the stream key identifies and authorises the stream; you need the values issued for the platform and stream you intend to use.
For YouTube, find both values in the Live Control Room, enter them in the encoder’s matching fields, and choose YouTube’s RTMPS option when your encoder supports it. Keep the key private, then check YouTube’s preview or stream health rather than assuming that entering the values guarantees a connection.
What an RTMP destination is
RTMP stands for Real-Time Messaging Protocol. In a live-streaming workflow, an encoder packages your audio and video and pushes that broadcast to an ingest endpoint, where the platform can receive it and make it available as a live stream. The destination is the receiving side of that hand-off; it is not a video file, a channel page, or a source from which the encoder downloads content.
A useful way to picture the process is to imagine addressing a parcel. The server URL is the delivery address for the platform’s receiving system. The stream key is the private identifier that tells the platform which live stream the incoming data belongs to and, depending on the platform, authorises the encoder to send it. The analogy has limits, but it makes clear why neither value normally replaces the other.
The values are provided by the platform, not chosen at random in the encoder. YouTube supplies details for the live setup you select; Twitch documents a separate Twitch ingest pattern and key. That is why a field labelled “RTMP destination” does not imply there is one universal address that works for every service. Use the current values shown by the service receiving your broadcast.
Your encoder may be software such as OBS Studio or a hardware device. Either way, it prepares the outgoing stream and needs a destination it can reach. For a practical look at how the video settings fit into a YouTube encoder workflow, see the guide to YouTube Live settings for 1080p 30fps H.264 in OBS. Those picture and encoding settings are separate from the destination: a correct destination cannot repair a poorly configured video signal, and a good video configuration cannot make a wrong destination correct.
Server URL versus stream key
The server URL tells the encoder where to send the connection. It is platform-specific and may also vary by protocol. For example, YouTube distinguishes an RTMP ingestion address from an RTMPS ingestion address in its documentation. Copy the address from the live setup you are using rather than typing in a remembered value or borrowing one from a different service.
The stream key is the accompanying value for the live stream. Treat it as a credential, not as a descriptive label. Twitch explicitly explains that a stream key identifies and authorises a stream and warns users not to share it. YouTube’s interface also treats the key as a value to copy into the encoder’s stream settings. It may look like a long string of ordinary characters, but appearance is no reason to publish it.
Encoders commonly show separate fields for “Server” or “Server URL” and “Stream Key”. Put the platform’s address in the server field and the platform’s key in the key field. If the tool offers a service preset, use the one for the platform and protocol you selected, then verify which values it expects. Some interfaces use a single combined field; YouTube’s API reference documents an address and stream name as distinct values, and notes the combined form used by some tools. Follow the field labels in your own encoder instead of forcing a combined value into a server-only field.
A destination is a pair of related values, but that does not mean the pair can be mixed and matched. A key from an old event, another channel, or another platform may not correspond to the address you have pasted. If you have several scheduled streams, label your own notes by channel and event without including the secret key in a shared document or screenshot. When in doubt, return to the platform’s current live setup and copy both values from there.
Find YouTube’s ingest details
In YouTube Studio, open the Live Control Room and choose the stream or scheduled event you plan to broadcast. In the stream settings, YouTube provides the encoder details. Its Help instructions for streaming with an encoder using RTMPS describe where to find and reveal the RTMPS address and where to copy the stream key. The interface can change, so use the current labels shown in your account if they differ from an older guide.
If you are choosing RTMPS, make sure you copy the RTMPS address, not simply the default RTMP address. Both belong to YouTube’s ingest service, but they identify different protocol choices. YouTube’s Live Streaming API reference separately lists the RTMP ingestion address, the RTMPS ingestion address, and the stream name in its ingestion information. That distinction matters when you select a protocol in an encoder or build a workflow that uses the API.
The address and key you see are for the live setup you selected. If you switch to another event, account, or channel, check the details again rather than assuming the previous destination carries over. A saved encoder profile is convenient, but a profile can retain stale values. Before starting, compare its destination with the currently selected YouTube stream.
After copying the details, keep them out of public chat, a screen recording, a support post, or a stream overlay. If you need help with an encoder, describe the field names and error message without posting the key. A redacted screenshot can show the server field and connection state while hiding the secret. This is especially important when you are working with a helper or contractor who needs to know how the fields work but does not need long-term access to the account’s stream key.
Enter destination values in an encoder
Open your encoder’s live-stream or output settings. If it has a service selector, choose YouTube and the appropriate protocol. Then either let the preset populate the endpoint and enter the key, or use the custom destination fields to paste the address and key supplied by YouTube. Do not put the key in a box that asks only for a server URL. If your encoder combines the values, use the format it documents rather than guessing at punctuation or adding characters to the address.
Before going live, check these items in order:
| Check | What to verify | Why it matters |
|---|---|---|
| Service and event | The selected YouTube account and live setup are the ones you intend to use | A valid key for another stream is not the destination you selected |
| Protocol | The encoder selection matches the address you copied, such as RTMPS with an RTMPS address | A protocol mismatch can prevent connection |
| Server field | The complete platform-provided address is in the server field | A missing or substituted endpoint sends the encoder to the wrong receiver |
| Key field | The matching stream key is in the key field and is not exposed publicly | The key identifies and authorises the stream |
| Signal check | YouTube’s preview or health panel receives data | A connection message in the encoder alone does not confirm a healthy stream |
Start the encoder and give the platform’s preview a chance to report whether it is receiving data. YouTube’s API describes active stream status and health information, including configuration issues. In the Studio interface, use the preview and health messages available for your stream to distinguish a destination problem from a signal or configuration problem. If the encoder reports a connection but YouTube does not show incoming data, recheck the selected event, address, protocol, and key before changing unrelated video settings.
Destination setup is one part of a working live channel. If the channel needs to repeat a prepared video continuously, the separate workflow described in how to loop a YouTube livestream with FFmpeg and a remote Linux server covers the ongoing playback side. A destination tells the encoder where the stream goes; it does not make the media loop, keep an encoder running, or manage a channel schedule.
Use RTMPS when appropriate
RTMPS is RTMP carried over a TLS/SSL connection. In practical terms, encryption protects the connection between the encoder and YouTube’s ingest service. YouTube’s protocol documentation distinguishes unencrypted RTMP from encrypted RTMPS and describes the latter for standard live-streaming use. For an ordinary YouTube software-encoder setup, use YouTube’s RTMPS preset when available, or copy the RTMPS address and follow the encoder’s current setup instructions.
Protocol and address must agree. If you select RTMPS but paste an RTMP address, the encoder may not establish the connection. YouTube’s developer guidance specifies port 443 for RTMPS. Many encoders handle the port as part of their preset; if you configure a custom endpoint, consult the encoder’s documentation and YouTube’s current instructions rather than changing ports by trial and error. The YouTube RTMPS setup guidance is the place to check when a timeout or SSL-related error persists.
A connection can also fail even when the visible address looks right. A custom client must handle TLS correctly, including the server hostname in the TLS Server Name Indication (SNI) handshake. YouTube’s RTMPS developer guide explains the endpoint, port, and TLS requirements. This detail is more likely to matter when you are using an API-based or custom implementation than when choosing a built-in encoder preset. If you use a standard encoder, first check its stated RTMPS support and confirm its preset is current.
RTMPS is not a promise that the broadcast will connect or remain healthy. Your internet connection, encoder configuration, stream status, and platform-side conditions still matter. If the encoder does not support RTMPS, do not assume that a different RTMPS-capable address will work in that encoder; check the manufacturer’s documentation and the platform’s current supported options. This article’s protocol guidance is specific to YouTube’s documented RTMPS workflow, not a claim that every platform offers identical endpoints.
Protect and reset a stream key
Keep the key private in the same way you would protect an account credential. Do not include it in a public screenshot, paste it into a public forum, or show the settings window during a live broadcast. Avoid storing it in a shared note that is accessible to people who do not need it. When you ask for support, redact the key and provide the error text, encoder name, selected protocol, and whether YouTube reports incoming data instead.
If a key has appeared on screen or reached someone who should not have it, treat it as exposed. Use the platform’s key-management controls to refresh or replace it, then update the encoder with the new value. Twitch documents a refresh control that changes the broadcaster’s key; for YouTube, use the controls currently shown in Live Control Room. A changed key can stop an encoder that still has the old value, so update any legitimate encoder profile or scheduled workflow that relies on it and verify the new signal in YouTube.
Take care when using a long-running channel. A stream can run for hours, but the encoder settings remain available to anyone who can access the device or account where they are saved. Limit access to those settings, sign out of shared machines when appropriate, and do not send the key as part of a routine status message. If you have to provide remote assistance, share only the minimum information needed and rotate the key afterwards if you cannot be confident it remained private.
For a channel that should run without leaving a computer switched on, a hosted workflow can remove the task of keeping a local encoder open. StreamNeo lets you upload a video, enter your YouTube stream key, and have the broadcast continue with your computer off; because the key remains the credential that connects the channel, enter it only in the intended account workflow and keep it out of public messages.
Why an RTMP destination may not connect
Begin with the smallest checks, in order. Confirm that the selected stream in YouTube is the one you meant to use, then copy its current address and key again. Check that the protocol selection matches the address prefix. If you chose RTMPS, verify that the encoder supports it and that a custom configuration uses the required port and valid TLS handling. Re-copying a paired destination is usually more useful than repeatedly restarting an encoder with values from an old profile.
Read the exact error rather than treating every failure as a key problem. A timeout can point to a protocol, port, network, or encoder-support issue. An SSL or certificate error makes the RTMPS configuration and TLS handling particularly relevant. If YouTube receives data but reports a configuration issue, the connection has reached the platform; investigate the health or encoder settings it identifies instead of continuing to replace the destination values without evidence.
If the destination checks out but the stream drops frames or stalls, look beyond the URL and key. Network packet loss and upload limits are different from ingest authentication; the Ethernet and packet-loss troubleshooting guide addresses that separate class of problem. Likewise, if YouTube shows no incoming data, use its stream preview and health indicators to establish whether the encoder is reaching the selected event before tuning bitrate or changing the media source.
For a custom integration, keep the platform’s protocol requirements close at hand. YouTube documents an RTMPS address and a distinct RTMP address; the right one depends on the client’s supported protocol. Confirm the hostname and port, and ensure the TLS handshake uses the expected server name. If these terms are unfamiliar and you use a standard encoder, avoid improvising low-level TLS settings: choose the documented YouTube preset or consult the encoder’s support material.
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
What do I put in the RTMP server URL and stream key fields?
Copy the server or ingest URL and matching stream key from the live setup on the platform receiving your broadcast. Paste each into the encoder field with the corresponding label, and confirm that the selected protocol matches the address. Do not use values copied from another platform or stream.
Where do I find my YouTube RTMP URL?
Open the intended stream in YouTube Studio’s Live Control Room and look in its stream settings. If you plan to use RTMPS, reveal and copy the RTMPS address rather than assuming the ordinary RTMP address is interchangeable. Copy the key from that same live setup.
Is RTMP the same as RTMPS?
RTMPS is RTMP sent through a TLS/SSL-encrypted connection. For YouTube, choose RTMPS when your encoder supports it, and pair the RTMPS selection with the RTMPS address. The platform’s instructions specify the connection requirements, including port 443.
Why is my RTMP destination not connecting?
Check the selected stream, server URL, key, and protocol first, then check encoder support and any required port or TLS settings. If the platform receives data but reports poor health, investigate the reported signal or configuration issue rather than treating it as a destination failure. Never post your stream key while asking for help.