Saving video, audio and subtitles offline: where a downloader stops

Every "video downloader" question eventually turns into the same argument: why can't it just give me the best quality, why is there no audio-only option on this page, why did the subtitle file come out empty. The answers are less about the tool and more about what the source page is willing to hand over.

These notes come from building and running Keep Video, a browser-based tool with an open-source desktop app, so they are written from the boring side of the problem.

The source decides the ceiling

A downloader resolves a media URL and lists what the source exposes. It does not re-encode a better version, and it cannot invent a 4K stream that the page never served. If a platform only ships a 720p progressive file to anonymous visitors, that is the ceiling. The same goes for containers: a tool can remux, but remuxing does not create data that is not in the stream.

The practical consequence for anyone building this: your UI should show the formats that actually came back from the extractor, not a fixed dropdown of "1080p / 720p / 480p". A fixed list lies to the user the moment the source changes.

Audio-only is a stream choice, not a conversion magic trick

Extracting audio is usually cheap because most sources already ship separate audio streams. What a tool should not promise is vocal removal or "improving" quality: if the source audio is a 64 kbps AAC track, an MP3 conversion will preserve the loss, not repair it.

For the desktop app we keep an audio guide that walks through MP3 conversion and the FFmpeg settings involved, because that is where the quality questions really live.

Subtitles are a track you either have or you don't

Subtitle handling is the most misunderstood part. SRT output means the source already had a subtitle track: text plus timecodes, no video processing. If a video has no captions, nothing is transcribed; that is a different product with a different cost model. The subtitle guide covers how track selection works and why storing the SRT next to its video file helps players pick it up.

Two rules that save support tickets:

1. Show the list of available languages from the source, not a hardcoded list.
2. Say "existing subtitles" in the product copy, and mean it.

Server-side processing or local processing

The browser tool at keep.video/app runs on a server: paste a public URL, get a finished file, no install and no account. That trade is convenience for two costs, the server does the work and the file sits in temporary storage until you download it.

The desktop builds for macOS, Windows and Linux flip that trade. Processing happens locally, there are queues and local file management, and you can use your own signed-in session for sources that need one. They also ask you to bring your own runtime dependencies (yt-dlp and FFmpeg are not bundled), which keeps the installer small and the licensing clean, at the price of one setup step.

What we refuse to write in the copy

• "Unlimited free" or "100% success" claims, because site support changes weekly.
• "No data leaves your device" for the online tool, because that is simply false.
• "Automatic transcription" for a subtitle saver.

If you are building something in this space, the honest limits are also the best documentation: quality is capped by the source, audio is a stream choice, subtitles only exist if the source has them, and local processing is a setup decision rather than a feature bullet.

The code is MIT licensed at github.com/oiov/keep.video, and the tool is at keep.video.

Only download content you own or have permission to save.