An IP camera can provide a live feed for a website, but its RTSP output is not something a browser can play directly. You need a media server or hosted relay to receive the camera stream and deliver it in a browser-friendly format such as WebRTC or HLS.
Start by confirming that your exact camera model supports RTSP, then decide whether low delay or wider playback compatibility matters more. Keep the camera feed private and expose only the protected player output to website visitors.
Why the camera feed needs a bridge
A camera and a web browser speak different streaming formats. Many IP cameras send video over RTSP, a protocol used to control and carry a stream from the camera to a receiving application. Browsers do not directly play an RTSP URL in a web page. Putting that URL in an HTML video element will not turn it into browser playback.
A media server or hosted relay sits between the two ends. It connects to the camera’s stream, then packages or forwards the video in a format that a player in the browser can use. The website embeds that player or its browser-compatible output, rather than exposing the camera’s RTSP address. Wowza’s IP camera overview describes this kind of RTSP ingest and browser delivery workflow.
ONVIF is related to camera interoperability, but it is not another name for RTSP. RTSP carries the stream; ONVIF supports interoperability and access to device capabilities. A camera may support one, both or neither in the way your planned setup requires, so check the model documentation rather than treating ONVIF support as proof that an RTSP feed is available.
The practical path is: camera, relay or media server, browser-compatible output, player on your site. Each stage can fail independently. A camera login problem is different from a relay connection issue, and either can be separate from an embed or browser problem. Testing each stage in order saves time.
Find the camera’s RTSP details
Begin with the camera’s exact model number and its official setup guide. Look for RTSP support, how to enable it, the stream path, the account credentials required, and any restrictions that apply to the camera’s power type or firmware. Do not assume that a URL pattern for one brand or model works on another. Even cameras sold under the same product family may have different capabilities.
Many vendors put RTSP settings in a local camera interface or app, sometimes behind an option to create a separate streaming account. If you are asked to make a dedicated account, use one with only the access needed for the stream. Do not paste a camera URL containing a username and password into a public page or a support forum.
The stream path may distinguish between a higher-quality and a lower-quality feed, but those paths are specific to the camera. TP-Link’s Tapo RTSP guide describes the supported products and setup for its own cameras; it is an example of why you should follow documentation for the exact device, not a template to copy for every camera. TP-Link also notes that wired Tapo cameras support RTSP and ONVIF, while many battery-powered models generally do not support RTSP. That is vendor guidance for its product line, not a universal rule for all cameras.
Once you have the documented URL and credentials, test the feed on a device on the same trusted local network. A compatible player such as VLC can help you determine whether the camera itself is reachable and whether the credentials work. If the local test fails, fix that first. A website relay cannot compensate for a disabled RTSP setting, an incorrect path, a stale password or a camera that does not offer RTSP.
Choose a media server or hosted relay
You need something to receive the RTSP feed and provide an output the site can play. A self-managed media server gives you control over the ingest and output configuration, but you also take responsibility for setup, updates, access control and troubleshooting. It is more suitable when you already manage streaming software and can monitor the system that sits between the camera and the website.
A hosted relay can package more of the workflow, potentially including a player, a watch page or embed instructions. Check the provider’s current documentation for the exact camera ingest method, output formats, access controls, recording or scheduling features, and any limits. Do not assume that a hosted service supports every camera or includes every feature just because it supports RTSP pull. OctoStream, for example, documents RTSP camera pull and browser embeds in its service overview; that is a description of its offering, not an independent comparison or a guarantee about another provider.
| Choice | What you control | What you need to maintain | When it may fit |
|---|---|---|---|
| Self-managed media server | Ingest, output configuration and deployment | Server setup, updates, network access and monitoring | You already operate streaming software and want direct control |
| Hosted relay | Usually the service’s available configuration and access settings | Camera connection, account settings, embed configuration and provider terms | You want a packaged route from camera feed to website player |
These choices do not have a universal cost, capacity or reliability ranking. Compare the current terms from the providers you are considering, and test the intended camera and player combination. Also consider whether the website is for a public scene, a shop entrance or a private room: the acceptable exposure and access controls differ substantially.
If your real goal is to keep a separate video programme on a 24/7 YouTube channel rather than show a live camera on your website, the setup is different. A guide to scheduling a playlist for an always-on YouTube stream covers a file-based broadcast workflow; an IP camera website embed instead depends on a live camera feed and a browser relay.
Select WebRTC or HLS for playback
WebRTC is the usual starting point when people need to see events close to real time, such as a live class, a two-way operational view or a public-facing scene where delay would make the feed less useful. HLS is often the better starting point when broad playback compatibility across devices matters more than keeping delay low. These are priorities, not guarantees: actual delay and playback behaviour depend on the camera, relay, network, player and target browser.
Do not select a format from a claim about a single typical delay. The sources for this workflow do not establish a universal end-to-end latency figure, and a value measured in one deployment may not hold for yours. Test using the actual camera and network, then decide whether the observed delay is acceptable for the job. A traffic view can tolerate more delay than a remote operator who needs to react immediately.
Compatibility is also a property of the whole path. The output format, player implementation, browser and device all matter. Ask the media server or hosted relay which playback options it exposes, and check the player’s requirements for your intended desktop and mobile browsers. Test on a phone using mobile data as well as on a computer on the same network as the camera; these are different paths and can expose different problems.
| Priority | Start by testing | Trade-off to check |
|---|---|---|
| Near-real-time viewing | WebRTC | The viewer’s browser and network must work with the selected WebRTC player and output |
| Broad device playback | HLS | The feed may have more delay than a low-latency setup |
| Unsure what viewers need | Both, if the relay supports them | More output choices can mean more configuration and testing |
If a camera captures a changing public scene, viewers may not mind a modest delay. If the feed is used to coordinate a response, it is worth measuring the delay from a visible event at the camera to the same event on the website. Treat that as a test of your installation rather than a performance promise. The useful decision is the one that matches the viewer’s task.
Embed the player on your website
Use the player or embed code provided by the media server or relay, and verify that it points to the browser-compatible output. Do not put the raw RTSP URL in the page and expect it to play. The player may be an iframe supplied by the service or a player you configure to read its output; follow the instructions for that specific option.
Test the page in the same way a visitor will use it. Check that the player loads without requiring access to your camera’s local network, that sound and controls behave as intended, and that the video resizes sensibly on a narrow screen. If the stream is meant for a restricted audience, confirm whether the embed can be limited to your domain, protected by login, or otherwise controlled. A public page containing an unrestricted live view is public even if the camera itself is mounted on private property.
Keep credentials out of page source and browser-visible settings. The camera’s RTSP address should be used by the relay as an ingest source, not handed to each viewer. The website should point to a protected relay output or player. When diagnosing, inspect the page and embed settings without copying secrets into screenshots, issue reports or analytics tools.
If this is part of a broader live video plan for a shop, venue or local business, the article on using live streaming for marketing may help you decide what viewers should see and when. That is a content decision, separate from the technical choice of a camera protocol or player.
Secure the camera-to-site path
Treat the RTSP feed as a private camera interface. Do not forward camera ports to the open internet simply to make the website player work. TP-Link’s camera support documentation warns against using RTSP and ONVIF on public networks and recommends trusted local networks; for remote camera viewing it recommends an encrypted VPN. That guidance is about access to the camera, not a substitute for securing the browser output on your site.
Prefer a design where the relay can reach the camera over a trusted network and viewers can reach only the intended player output. Protect that output when the video is not meant for everyone. Use separate credentials where supported, change default passwords, and remove access that is no longer needed. If you require remote administration of the camera itself, follow the manufacturer’s secure access guidance rather than exposing its management interface as a shortcut.
Access control needs to match the scene. A public weather or harbour view may be deliberately open, while a feed from a workplace, home or customer-facing area may reveal people, routines or private information. Decide who is allowed to watch, where the image may be shown, and whether recording is appropriate before publishing the embed. Check the current official guidance from your camera vendor and relay provider, because their supported security options can change.
ONVIF’s Profile V documentation describes a profile covering video and audio streaming and related functions, but standards support alone does not configure or secure your deployment. Confirm the camera’s actual profile support and the features your chosen software uses. A standards label is useful for interoperability checks; it is not a promise that every device exposes the same stream or access controls.
Test the exact camera and deployment
Work from the camera outwards. First confirm that the camera is powered, reachable on the local network, and configured to expose the documented stream. Then play it locally using a compatible player. Next check that the relay can connect with the same URL and credentials. Finally load the website player on the devices your viewers are likely to use. This sequence identifies which stage needs attention instead of leaving you to guess whether the camera, network, relay or page is at fault.
Test a deliberate interruption. If the network drops or the camera restarts, observe whether the relay recovers and whether the website player resumes or needs refreshing. Test expired or changed credentials as well, and confirm that a failure does not expose a login prompt or camera address to viewers. A clean test in one browser is not a universal compatibility result, so try the desktop and mobile combinations that matter to your audience.
For a website that is simply a page in a wider live-video operation, keep the two workflows distinct. A camera-to-web relay serves visitors on a site; it is not the same as a YouTube broadcast encoder or an always-on playlist. If you are also running a YouTube channel, the practical advice on keeping a VPS-based 24/7 stream from getting stuck addresses a different part of that operation.
Write down the working camera model, firmware, stream path, relay settings and player configuration in a private operations note. Keep secrets in a password manager, not in that shared note. When something changes, such as the router, camera password or relay service, you will have a baseline to compare against.
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
Can I view an IP camera remotely in a web browser?
Yes, but typically not by opening the camera’s RTSP address directly in the browser. Use a media server or hosted relay to receive the camera feed and provide a browser-compatible player or output, then secure that output for the intended viewers.
Is RTSP or ONVIF better?
They do different jobs, so it is not a direct either-or choice. RTSP is used to stream video, while ONVIF supports interoperability and device capabilities; check which functions your camera and software actually support.
How do I find my IP camera RTSP URL?
Check the exact model’s official documentation or camera interface for RTSP enablement, the stream path and the required account. Do not copy a URL from another model without confirmation, then test the documented address locally with a compatible player before configuring a relay.
Should I choose WebRTC or HLS?
Start with WebRTC when lower delay is important, and HLS when broader device compatibility is the stronger priority. Test the complete camera-to-player path on the browsers and networks your visitors will use, because neither format guarantees a particular delay or universal playback behaviour.