ReClip: a self-hosted yt-dlp front end with a web UI and two dependencies

What ReClip actually replaces

The tedious part of yt-dlp is not the download. It is remembering the flag combination for audio-only extraction, checking which formats a given page offers, and re-pasting a URL after a typo. ReClip puts a form in front of that: you paste one or more links, pick MP4 or MP3, click Fetch, and the page loads titles, thumbnails and available resolutions before anything is written to disk. The audience is narrow and specific. It is someone who already runs yt-dlp, wants a browser tab instead of a terminal, and is comfortable hosting a Python process on a machine they control. The README is explicit that the tool is for personal use and that respecting copyright and platform terms is the user's responsibility, not the project's.

How the Flask backend drives yt-dlp

The repository layout is unusually flat and that is the architecture. app.py is a single Python file described in the README as roughly 150 lines; templates/ and static/ hold the front end, which the README says is vanilla HTML, CSS and JavaScript with no build step. The download engine is yt-dlp for fetching and ffmpeg for muxing and audio conversion, and requirements.txt lists exactly two Python packages, flask and yt-dlp. In the container image, gunicorn is installed separately and started with a single worker and four threads, so concurrency comes from threads, not processes. The Dockerfile also sets PATH so that the reclip user's local binary directory comes first, with a comment stating this is so startup yt-dlp updates take effect. That detail tells you the intended upgrade path for the extractor is inside the running container, not a rebuild.

Installing ReClip and running a first download

The README's quick start assumes macOS Homebrew for the two system tools, with an apt and pip alternative in the same line. The script at the repository root is the entry point, and the README states the UI is then reachable on port 8899.

brew install yt-dlp ffmpeg    # or apt install ffmpeg && pip install yt-dlp
git clone https://github.com/averygan/reclip.git
cd reclip
./reclip.sh

If you would rather not install Python tooling on the host, the README gives a one-line Docker path. The image is built from the local Dockerfile, which installs ffmpeg from the distribution packages and runs the app under gunicorn on the same port.

docker build -t reclip . && docker run -p 8899:8899 reclip

For a persistent setup, docker-compose.yml defines a single service that builds the same image, maps 8899, mounts a named volume at /app/downloads, and sets restart: unless-stopped. The volume is the part worth noticing: without it, a container rebuild discards whatever you downloaded.

services:
  reclip:
    build: .
    image: reclip:latest
    container_name: reclip
    ports:
      - "8899:8899"
    volumes:
      - reclip-downloads:/app/downloads
    restart: unless-stopped

Once the page loads, the README's flow is: paste one or more URLs, choose MP4 or MP3, click Fetch to load info and thumbnails, pick a quality or resolution if the site exposes options, then click Download on a single item or Download All. Expect the Fetch step to take a moment on sites where yt-dlp has to resolve a manifest, and expect the download itself to hold the connection open, which is why the gunicorn timeout in the Dockerfile is set to 600 seconds.

Where ReClip stops being the right tool

The README documents no authentication layer. It describes a web UI on localhost, the Dockerfile binds 0.0.0.0:8899, and nothing in the documented configuration adds a login, an API key or a reverse-proxy hint. Anyone who can reach the port can queue downloads to your disk. That makes it a personal or trusted-LAN tool, not a shared service, and it is the first thing to think about before exposing it beyond your own machine. The second limit is the single-worker gunicorn configuration. Four threads means four concurrent downloads in the container path; a fifth request waits. Bulk pasting many URLs is supported, but the README does not describe a queue with progress reporting, so the practical ceiling is the thread count rather than the number of links you paste. Third, ReClip inherits every yt-dlp breakage. When a platform changes its player, downloads fail until the extractor is updated, and the Dockerfile's PATH comment suggests the project expects that update to happen at runtime rather than through a new release. The repository has no published GitHub releases, so there is no changelog to check when something stops working.

ReClip versus calling yt-dlp directly

The honest alternative is yt-dlp itself, and the difference is not capability but surface. yt-dlp gives you format selection strings, playlists, subtitles, cookies from a browser profile, and a configuration file; ReClip gives you a thumbnail grid, a resolution dropdown and a Download All button. If your job is a one-off grab from a known URL, the CLI is fewer moving parts and no port to expose. If your job is repeatedly pulling a handful of links from several sites and you would rather not look up the audio-extraction flags each time, the web UI earns its place. The other comparison worth naming is a general media server such as Jellyfin or Plex, which handles libraries, metadata and playback. ReClip does none of that. It downloads files into a folder and stops there, which is why it fits next to a media server rather than in place of one.

Maintenance, upgrades and the MIT licence

The last push to the default branch was on 2026-07-09, so the project is not archived but has been quiet for almost four months. That is not a verdict on quality, but it does mean the maintenance you should plan for is mostly yt-dlp's release cadence, not ReClip's. The Dockerfile's PATH ordering exists precisely so that a yt-dlp upgrade inside the container takes effect on the next start, which is the cheapest upgrade route the repository shows. A rebuild from the Dockerfile re-runs pip install -r requirements.txt, and because requirements.txt pins nothing, that pulls the current flask and yt-dlp rather than a tested pair. If you need reproducible builds, pinning those two lines yourself is the only mechanism the repository offers. On licensing: the project is MIT, so you can use, modify and redistribute it, and the LICENSE file is at the repository root. The README's disclaimer separates the code licence from the content question, placing responsibility for copyright and platform terms on the user. That is not legal advice and the disclaimer is not a legal opinion; if your use is commercial or public-facing, treat the disclaimer as a boundary the project has drawn, not as permission.

Editorial conclusion

Adopt ReClip if you already trust yt-dlp and want a local browser front end for it without running a full media server; the Dockerfile runs as a non-root user and the compose file keeps downloads in a named volume. Skip it if you need authentication, per-user quotas, or a hosted service, because the README documents none of those, and skip it on phones, since there is no Android or iOS build and the UI is served from your own host. Verify three things before relying on it: that yt-dlp and ffmpeg are on PATH in your chosen install path, that the downloads volume in docker-compose.yml is the one you intend to keep, and that your use of the source site complies with its terms, which the README's disclaimer puts on you rather than the project.

Frequently asked questions

Official sources

1. averygan/reclip on GitHub
2. Issues
3. License: MIT
4. README