Download without the clutter: building Grabbr

If you have ever tried to download a video or save the audio from a clip you have the rights to, you probably know the experience. You search for a video downloader, land on a website covered in ads, click one of four buttons labelled DOWNLOAD, and end up on a page asking you to allow notifications. Grabbr is our answer to that. We describe it in one line: download video and audio without the clutter. It is still being built, it is not released yet, and it is meant for macOS, Windows and Linux.

This post is about why we are making it, the design rules we set ourselves, some of the general engineering behind any downloader of this kind, and the part that matters most to us, which is using a tool like this responsibly.

The problem with download sites

Web-based download sites have a business model problem. Running the servers that fetch and convert video is expensive, and the people using the site usually do not pay. So the site pays for itself with advertising, and the incentives pull in one direction. More ads, more pop-ups, more redirects, and buttons designed to be confused with the real one.

That is annoying at best. At worst it is a security problem. Fake download buttons are a classic way to push unwanted software, browser extensions or notification spam onto people who were only trying to save a clip. The actual file you wanted can also be re-encoded at lower quality, since the site is paying for bandwidth and processing on every request.

There is a privacy side as well. Every link you paste into one of these sites tells a third party what you are watching, along with whatever the ad networks on the page collect. For something as ordinary as saving a lecture recording, that is a lot of exposure.

A desktop app changes the economics. The work of fetching and assembling files happens on your own computer, over your own connection. There are no servers of ours to pay for per download, so there is no reason to fill the screen with ads.

Design principles: paste, pick, done

We wrote the rules down before we designed a single screen, and we kept them short:

• Three steps. Paste a link, pick a format, done. Anything that adds a fourth step has to justify itself.
• No account. You should not need to sign up, sign in or hand over an email address to save a file to your own disk.
• No ads. Not a few tasteful ones. None.
• Sensible defaults. Most people want the best quality that plays everywhere, saved to their Downloads folder. That should be what happens if they do not touch anything.
• Honest progress. If something is slow or fails, say what happened in plain words, not a spinning circle that never ends.

The format step is where most of the design thinking went. Behind the scenes, a single video can be available in a dozen combinations of resolution, codec and container. Showing all of them is technically complete and practically useless. The idea is to group choices by what people actually want, such as a video at a given quality or just the audio, and to keep the full detail one step away for people who care about it.

Under the hood: formats and codecs

Here is the part that surprises people who have never built a downloader. On many large video platforms there is no single "video file" to download. Modern streaming uses adaptive formats such as DASH and HLS, where the player picks from many versions of the video at different bitrates and switches between them as your connection changes. Higher quality versions are frequently delivered as separate streams: one for video with no sound, one for audio with no picture.

So format selection is really a matching problem. Given what is available, a downloader has to pick a video stream and an audio stream that together match what the user asked for, and that will play well on their machine. Codecs matter here. H.264 video with AAC audio plays almost everywhere. Newer codecs such as VP9 and AV1 are more efficient, so the same quality takes less space, but older devices and some editing software handle them less well. We think the default should favour files that just play, with the more efficient options available for people who know they want them.

Muxing audio and video

Once you have separate video and audio streams, they need to be combined into one file. This is called muxing, short for multiplexing. The good news is that it usually does not require re-encoding. The compressed video and audio data can be copied as they are into a container such as MP4, WebM or MKV, with the timing information that keeps them in sync. That makes muxing fast and lossless.

The catch is that not every codec fits in every container. H.264 and AAC fit neatly in MP4. VP9 or AV1 with Opus audio are at home in WebM or MKV, and while MP4 can technically carry them, support in players and editors is patchier. When the streams and the requested container do not fit together, the options are to change the container or to re-encode, which takes time, uses a lot of CPU and loses some quality. Our preference is to avoid re-encoding whenever possible and to be clear with the user when it is needed.

Audio only is the simpler case, but it has its own choice. You can keep the original audio stream as it is, which is fastest and loses nothing, or convert it to a more familiar format such as MP3 for older players, at a small cost in quality.

Resuming and reliability

Large files and home internet connections do not always get along. A download that fails at 90 percent and starts again from zero is one of the most frustrating things a computer can do. Most web servers support HTTP range requests, which let a client ask for bytes from a given offset onwards. A careful downloader writes to a temporary file, remembers how much it has, and asks only for the rest after a dropped connection.

Segmented streaming formats make this a little easier in some ways, since the content is already split into many small pieces that can be retried one at a time. It also means there are many more requests that can fail, and each one needs sensible retry and back-off behaviour so the app does not hammer a server.

The final step is making sure the file is actually complete before calling it done. That means checking sizes, making sure the mux step finished, and only then moving the file from its temporary name to its final one. A half-written file with a normal name is worse than an error message, because you only discover it when you try to play it later.

Using it responsibly

A download tool is exactly as good or bad as what it is used for, and we want to be direct about this. Only download material you have the right to download. That includes your own uploads, content published under a licence that allows it (many Creative Commons works, for example), material in the public domain, and anything the rights holder has clearly allowed you to save.

Many platforms also have terms of service that restrict downloading, whatever the copyright position of a particular video. Those terms apply to you as the user, and you should read and respect them. Downloading a film or a paid course to share it, or to avoid paying for it, is not something we want Grabbr used for once it ships. It also hurts the creators whose work makes these platforms worth visiting in the first place.

The good uses are ordinary ones. Keeping an offline copy of a talk you gave. Saving a lecture your university published so you can watch it on a train. Archiving your own channel before you close an account. Pulling the audio from a recording of your own band.

Grabbr is listed as coming soon with our other desktop apps, and like them it is meant to do one job and then get out of the way. The test we keep coming back to is the one from the drawing above: a person who has never used it should be able to paste a link and get a file without reading anything, and without clicking a single thing they did not mean to.