← Back to blog

How to Record Live Streams in Chrome Browser (No OBS Needed)

Three ways to record HLS live broadcasts directly in Chrome — without screen-recording, without OBS, and without losing quality.

Recording a live stream in Chrome doesn’t have to mean firing up OBS, configuring Window Capture, and re-encoding hours of video while your CPU melts. If the live stream is HLS — and most live streams in 2026 are — you can record it as a direct stream copy with bit-for-bit fidelity, no re-encode, and no screen-recording overhead.

This guide explains the difference between screen recording and stream recording, why direct HLS recording is almost always better, and three ways to do it in Chrome.

Screen recording vs stream recording

Most “record a live stream” tutorials online point you at screen-recording tools — OBS, Loom, Screencastify, or the OS’s built-in screen capture. These tools capture what’s on your screen, which means:

  • Video gets re-encoded to your recorder’s codec settings (typically lossy H.264 with the recorder’s bitrate)
  • Audio is captured through your OS audio loopback, often at 48 kHz when the source was 44.1 kHz
  • Resolution caps at your screen resolution — 1080p screen can’t record 4K source
  • Anything that pops up on your screen during the recording (notifications, mouse cursor) ends up in the file
  • CPU and GPU stay busy the entire time the stream runs

Stream recording captures the HLS segments as they arrive from the CDN. The file you end up with is bit-for-bit the same data the player downloaded. No re-encode, no audio loopback, no resolution cap below the source, and minimal CPU usage because the work is just copying bytes from the network to disk.

If the source is 4K and your screen is 1080p, stream recording gets you 4K. Screen recording gets you 1080p.

How HLS live streams work

A live HLS broadcast is an m3u8 manifest that updates every few seconds. Unlike a VOD manifest (which lists the entire video upfront), a live manifest is a sliding window of the most recent ~30-60 seconds of segments. The player polls the manifest, fetches new segments as they appear, and discards the old ones from its buffer.

To record a live stream, a tool needs to:

  1. Identify the master playlist URL
  2. Resolve to a media playlist at the desired quality
  3. Repeatedly fetch the manifest (every 2-10 seconds depending on segment duration)
  4. Download each new segment as it appears
  5. Append segments to the output file in order
  6. Continue until the manifest stops updating (the stream ends) or the user stops the recording
  7. If audio and video are in separate manifests, do all of the above twice in parallel and merge

This is fundamentally different from VOD download because there’s no “end” to look for upfront — the recorder must keep polling until you tell it to stop.

Method 1: Chrome extension with live recording

A browser extension is the simplest path because it inherits the browser’s session (cookies, headers, signed URLs) and runs continuously while you keep the tab open.

Video Downloader One-for-All handles live HLS recording with these specifics:

  1. Open the live stream in Chrome
  2. Wait for playback to start (a few seconds)
  3. Click the extension icon — toolbar badge turns blue, dropdown shows the available qualities
  4. Pick the quality and click “Start Recording” (vs the regular “Download” button used for VOD)
  5. Leave the tab open while the recording runs
  6. When the stream ends or you want to stop, click “Stop Recording”
  7. The extension finishes any in-flight segments, runs FFmpeg.wasm to mux audio + video, and saves an MP4

The MP4 is bit-for-bit the same data as the live broadcast. No re-encode loss.

For the technical context on why HLS is structured this way and what the manifests look like, the HLS guide walks through the protocol from the ground up. For the full feature surface, see the Live Stream Recorder page.

Method 2: yt-dlp with --live-from-start

yt-dlp can record live HLS, with caveats:

# Record from now until manual stop or stream ends
yt-dlp "https://www.example.com/livestream"

# Record from the beginning of the live stream (if the manifest still has early segments)
yt-dlp --live-from-start "https://www.example.com/livestream"

# Limit to a specific duration
yt-dlp --download-sections "*0:00:00-1:00:00" "https://www.example.com/livestream"

Caveats:

  • --live-from-start only works if the manifest still has the early segments (the live window is usually 30-60 seconds, so this rarely captures more than the last minute before you started)
  • yt-dlp’s live HLS reliability is mixed; some streams produce gaps when the manifest rotates faster than yt-dlp polls
  • Sub-only or auth-required live streams need --cookies-from-browser chrome

For straightforward public live streams, yt-dlp works. For anything behind auth or with aggressive token rotation, the browser-extension path is more reliable because it doesn’t have to re-implement the browser’s session handling.

Method 3: FFmpeg with live HLS flags

FFmpeg can record live HLS with the right flags:

ffmpeg \
  -live_start_index -1 \
  -i "https://example.com/master.m3u8" \
  -c copy \
  -t 02:00:00 \
  output.mp4

The -live_start_index -1 tells FFmpeg to start from the most recent segment available. The -t 02:00:00 caps the recording at 2 hours. Without -t, FFmpeg records until the stream ends or you Ctrl+C.

For separate audio/video manifests:

ffmpeg \
  -i "https://example.com/video.m3u8" \
  -i "https://example.com/audio.m3u8" \
  -c copy \
  -t 02:00:00 \
  output.mp4

The FFmpeg approach works but is fragile against:

  • Master playlist URL expiration (most live streams sign URLs that expire in minutes)
  • Network hiccups that cause segment fetches to fail (FFmpeg can be configured to retry but the defaults are conservative)
  • Live streams where the CDN requires a Referer header that FFmpeg doesn’t auto-set

Why screen recording is still occasionally the right answer

There are a few cases where screen recording beats stream recording:

  1. DRM-protected live streams — Netflix, Disney+, HBO Max, Amazon Prime Video, and similar services use Widevine or PlayReady DRM. None of the HLS-recording methods work; the encrypted segments are unplayable without the DRM key. Screen recording captures what the player decodes to your screen, which is unprotected at that point. (Whether this is legal in your jurisdiction is a separate question.)

  2. Multi-source layouts — If you want to record a stream plus a chat panel on the side, plus a webcam overlay, screen recording is the only way to capture them as a single composite.

  3. Extremely DRM-adjacent platforms — Some platforms detect HLS download attempts and serve different (often degraded or blocked) manifests. Screen recording bypasses that detection.

For 95% of public live streams, stream recording is faster, cleaner, and higher-quality. Screen recording is a fallback when the stream-recording path is blocked.

Common live-stream gotchas

Live manifest URL expires every 60 seconds

Most live HLS manifests are signed URLs that expire in 60-300 seconds. If you copy a manifest URL and try it 10 minutes later, you get a 403. Solution: use a tool that runs in the browser context (extension) so it always has a fresh URL.

Audio drifts out of sync after long recordings

Live audio and video manifests can drift in their timestamp bases. After several hours, naive concatenation produces audible drift. Our extension auto-corrects up to ~500 ms of drift; FFmpeg with -fflags +genpts helps but isn’t perfect for very long recordings.

Stream starts and stops while I’m recording

Some live streams pause and resume (commercial breaks, technical issues). The HLS manifest may briefly have no new segments. The extension and yt-dlp both handle this by polling indefinitely; FFmpeg with default flags may exit early — pass -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 10 to make FFmpeg retry.

My computer goes to sleep mid-recording

Recording stops when the system sleeps. Make sure your power settings prevent sleep during long recordings, or use a desktop where this isn’t an issue.

Can I record while doing other things?

Yes — the recording happens in a background tab and uses very little CPU (network I/O is the bottleneck, not encoding). You can browse other sites, work on other tabs, even close and reopen Chrome (the extension persists the recording state).

Comparison: which method when

SituationBest method
Twitch live streamBrowser extension or download VOD after
Public broadcast (news, sports)Browser extension
Sub-only live with authBrowser extension (inherits session)
Headless server / unattended scriptyt-dlp or FFmpeg
Long recording (> 4 hours)Browser extension or FFmpeg with reconnect flags
DRM-protected liveScreen recording is the only legal path; check your jurisdiction

Bottom line

If a live stream is HLS — and most are — you can record it as a direct stream copy without OBS, without re-encoding, and without screen-recording overhead. The simplest path is a browser extension that runs in the same tab as the player. yt-dlp and FFmpeg are good fallbacks for headless or scripted use.

Install Video Downloader One-for-All and the live recording workflow is two clicks: Start, Stop. The output is a bit-for-bit MP4 of what was broadcast.