Grabber (imgbrd-grabber): a booru downloader built around filenames
Very customizable imageboard/booru downloader with powerful filenaming features.
At a glance
- What is it?
- Grabber is a cross-platform imageboard downloader whose real feature is its naming engine: you define a filename pattern from image metadata and the program builds the directory tree. Here is how it installs, how sources and cookies work, and where it stops being the right tool.
- Who is it for?
- Adopt Grabber if you already know which boorus you pull from and you care about how the files land on disk: the token-based filename patterns and the JavaScript option are the reason to pick it over a script.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Grabber actually solves, and for whom
Grabber is an imageboard and booru downloader. Its stated goal is to download thousands of images from multiple boorus, and the README frames the naming features as the differentiator: you set a filename and a save directory using tokens, and the program generates the filename from the image's own information. That is a specific claim, and it is the one that separates this project from a shell loop around a JSON API. If you only need ten files, a loop is fine. If you want an artist/copyright/character directory tree built automatically from tags, you are the intended user.
The README lists Windows, Mac and Linux as supported desktop platforms, with separate install pages for Android, so mobile is treated as a real target rather than an afterthought. The interface is available in English, French, Russian, simplified Chinese and Spanish. The audience is therefore someone who browses boorus interactively and wants the downloaded result organized, not someone running a backend job.
Sources, tabs and the search pipeline
The browsing side is built around tabs, and a single tab can show results from multiple imageboards at once. The README also states that duplicate results from a multi-imageboard search are removed, which matters when the same post is mirrored across Danbooru, Gelbooru, Konachan and rule34. Tag auto-completion works in the search field, and blacklisting can either mark or hide images you do not want to see.
Two mechanisms are worth calling out because they change how you search. Post-filtering exists for cases where the imageboard's own search is limited, so the filtering happens on your side after results arrive. Auto-download runs as you search, gated by a whitelist, which turns browsing into a background fetch. Both are opt-in behaviours rather than defaults, and both are the kind of setting that quietly decides how much traffic you generate.
The default source list is long and includes Danbooru, Gelbooru, E-Hentai, Pixiv, yande.re, Shimmie, e621, Konachan, rule34, safebooru, Anime-Pictures, behoimi, Zerochan and Twitter. That list is also the honest limit of what is maintained for you: anything outside it depends on you writing a source definition.
Installing Grabber and running a first download
Grabber ships as prebuilt releases. The README points at the latest release page and at the full release list, and it links separate install documentation per platform (Windows, Linux, macOS, Android) on bionus.org. There is no package manager command in the README, so the release page is the entry point.
On Linux and macOS the README also documents building from source at the repository root:
./build.sh
./build-mac.shThe first runs on Linux, the second on macOS. The README points to the Compilation documentation for the full build requirements, which it does not list inline.
For a first real use, the filename pattern is the thing to configure before you download anything. The README gives this example of a save format:
%artist%/%copyright%/%character%/%md5%.%ext%With that set, each image is written under a directory path derived from its tags, and the file itself is named by its MD5 plus the original extension. The README states that JavaScript code can be used instead of the token format, and links a Filename documentation page for the details. A nightly build is produced automatically on every commit to the develop branch; the README warns it may be less stable than official releases.
Cookies, logins and sources behind a wall
Several of the default sources require authentication. The README lists authentication for sources behind a login wall as a feature, and the related searches suggest cookies are a recurring point of confusion for users. The mechanism is not spelled out in the README itself; the documentation is where the cookie handling is described.
This is the first place a large download can fail in a way that looks like a bug. If a source expects a session and the cookie is missing or expired, the search returns nothing rather than returning an error you can act on. Before blaming the tag syntax, check the cookie state for that source. The same applies to the proxy support the README mentions: a proxy that is set but not reachable produces the same empty-result symptom.
Saving into a local booru and post-download commands
Grabber is not only a file writer. The README states that images can be saved directly to a local booru such as Szurubooru, MyImouto, Gelbooru or Shimmie, with a documentation page per target. It also states that entries can be added to a database for each image or tag while downloading, through the Commands mechanism.
This is a different design from a downloader that writes files and stops. Grabber treats the download as one step in a pipeline that can end in another application's database. The trade-off is that those integrations are per-target and documented individually, so the amount of work scales with how many destinations you configure. If you only ever write to a filesystem, most of this surface is dead weight you will never touch.
Where Grabber is the wrong tool
The README presents a command line interface to download images, but it does not document the flags, the exit codes or the output format. That is a real gap if your plan is to call Grabber from a cron job or a CI pipeline: you cannot verify from the README alone how a partial failure is reported, or whether a successful exit means every image was written. Treat the CLI as something to inspect in the documentation before you depend on it.
The GUI does not have a native headless server mode in what the README describes. There is no mention of a daemon, a web interface or a scheduled sync. Grabber is a desktop application you drive, on Windows, Mac, Linux or Android. If you need a service that watches tags and ingests new posts continuously without a human in front of it, this is not that.
There is also a licensing and etiquette dimension the README does not address: downloading thousands of images from a booru is a load on someone else's infrastructure, and the project's own documentation is silent on rate limiting. That silence is not permission.
How Grabber differs from a gallery-dl style script
The closest comparison in spirit is a general-purpose media extraction tool such as gallery-dl, which is driven by configuration files and command line invocations and is designed to run unattended. The difference is where the complexity lives. Grabber puts a graphical browser, tabs, tag auto-completion and blacklists in front of the download, and pushes the configuration into filename tokens and optional JavaScript. gallery-dl-style tools put everything in a config file and expect you to script around them.
If you want a one-shot batch job on a server, the script approach fits better, because you can read its exit behaviour and wire it into a scheduler. If you want to browse, filter visually and land files in a structured tree without writing that tree logic yourself, Grabber's token engine is the more direct route. Neither is a superset of the other.
Maintenance, licensing and the cost of upgrading
The repository is not archived, and the last push was on 2026-09-13. The most recent release is v7.14.0 from 2026-08-14, following v7.13.0 in January 2025 and v7.12.2 in May 2024. The release cadence is uneven: a long gap between v7.12.2 and v7.13.0, then a shorter one to v7.14.0. Plan upgrades around releases rather than around a schedule, and expect the nightly builds on the develop branch to move faster than the tagged ones.
The licence is Apache-2.0, and the repository carries a NOTICE file alongside LICENSE. Apache-2.0 permits commercial use and modification and includes an explicit patent grant; it also requires that you preserve the licence and NOTICE when you redistribute. If you fork Grabber or ship a modified build, that obligation follows the code. This is a description of the licence text, not legal advice.
The practical upgrade cost is your configuration, not the binary. Filename patterns, custom sources and per-source cookies live in your setup, so a release that changes how a source is parsed can break downloads without breaking the application. Keeping your patterns in a place you can diff is cheaper than reconstructing them after an upgrade.
Editorial conclusion
Adopt Grabber if you already know which boorus you pull from and you care about how the files land on disk: the token-based filename patterns and the JavaScript option are the reason to pick it over a script. Skip it if you need a headless service, a scheduled sync, or a stable scripting interface, because the project documents a command line interface but the README does not describe its flags, exit codes or output format, and that is the first thing to verify before you build automation on top of it. Check the install page for your platform and the cookies documentation for any source behind a login before you plan a large download.
Frequently asked questions
How do I use Imgbrd-Grabber?
Download a release from the GitHub releases page, then use the search field to browse one or more imageboards in a tab. Before downloading at scale, set your filename pattern and save directory so the files land in the structure you want.
how to use imgbrd grabber
The README frames the workflow as: set your filename and save directory using the available tokens, and the program generates the filename from the image's information. A tab can show results from multiple imageboards at once, and duplicates are removed.
Is Grabber available for Android?
Yes. The README links a dedicated Android install page alongside the Windows, Linux and macOS pages, and android is one of the repository's topics.
Which imageboards does Grabber support by default?
The README lists Danbooru, Gelbooru, E-Hentai, Pixiv, yande.re, Shimmie, e621, Konachan, rule34, safebooru, Anime-Pictures, behoimi, Zerochan and Twitter as included sources, and states that additional sources can be added.
Can I change how downloaded files are named?
Yes. The README gives %artist%/%copyright%/%character%/%md5%.%ext% as an example format, and states that JavaScript code can be used instead of tokens, with a separate Filename documentation page.
Is there a nightly build of Grabber?
The README states that a nightly version is built automatically on every commit to the develop branch and can be downloaded from the nightly releases page, and warns that it may be less stable than official releases.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/bionus-imgbrd-grabber)