Documentation

Browser profile reuse

When you want a page to open with an account you already have, the app does not read your live browser profile in place. It builds a working profile: a copy of the cookies, local storage, and session data for the browser profile you select, written to a separate directory under the app's working-profile root.

Creating a working profile

1. Press Detect browsers & profiles in the browser session panel. The app lists installed browsers and their profiles only after you ask it to. Nothing is scanned silently.
2. Pick a source browser and profile, keep Use existing browser session checked, and authorize access with the consent checkbox.
3. Press Create Working Profile. The migration result shows the strategy used, any warnings, and a status: completed, partial, or failed.
4. Open the target page with the working profile. The page loads inside the target browser with the copied state.

Manual-login fallback

If the copy cannot complete, the target page still opens. Sign in once in the target browser window and continue. That session is then held by the working profile for later runs. Manual login is always a supported path, never an error state.

Working profile lifetime

Working profiles are listed in the session panel with a clear button each. Retention is configurable in settings; old work profiles become eligible for cleanup after the retention window. Cookie and token values never leave the device, and migration results record status and warnings only, never secrets.

Supported browsers

Media detection

Analysis runs on the page you opened, in three passes. Each pass reports the same candidate shape, so the list mixes sources without hiding where each row came from.

Network capture

Every request the page makes is inspected for media signatures: video file extensions and content types, HLS playlists (.m3u8), DASH manifests (.mpd), and segment sequences. This is the primary pass and works on most sites, including ones with custom players.

Video elements

HTMLMediaElement sources on the page are read directly, including blob URLs a player built from captured streams. Rows found this way carry the frame URL they were observed in.

yt-dlp fallback

Pressing Analyze videos also runs the yt-dlp pass, which enumerates formats against the page URL. These rows are labeled as yt-dlp formats and carry a format id and note. The auto-fallback setting runs this pass when capture finds nothing.

How rows are ranked

Candidates are ordered by the main process: direct files first, then HLS, then DASH, then unknown. The list shows resolution, duration, size when known, and whether the request needs your session cookies. Streams observed only as loose segments appear as low-confidence.

Download strategies

Direct HTTP downloads file candidates as they are served. FFmpeg probes HLS and DASH manifests, downloads the segments, and remuxes into MP4 or MKV. yt-dlp handles extractor formats, optionally with session cookies from the working profile.

Downloads run in a queue with live progress, speed, and byte counts. Active tasks can be cancelled; finished tasks show the output path on disk.

DRM policy

Protected content is not bypassed. If a stream sits behind a DRM system (Widevine, FairPlay, PlayReady), the app surfaces the detection as unsupported and does not offer a download. There is no key extraction and no CDM workaround in any tier.

When a row shows Protected content — not supported, it stays visible for information and its download control is absent. If you own the content, use the source the rights holder provides.

Troubleshooting