Booru Bulk Downloader (Userscript)

Booru Bulk Downloader is a browser userscript written by August Casso that puts download controls directly onto booru gallery pages, so full-resolution originals can be pulled in bulk without ever opening a post page.

This is the one piece of software in the archive written for a general audience rather than for August's own work: it exists because scraping a gallery one post at a time is a waste of an evening.

The Script

Version: 1.0.1
License: MIT
Size: ~44 KB / 1,122 lines
Runs on: Tampermonkey, Greasemonkey, Violentmonkey

Install

Greasy Fork: greasyfork.org/en/scripts/599354-booru-bulk-downloader
GitHub (canonical source): github.com/Reduxed/booru-bulk-downloader
OpenUserJS: openuserjs.org/scripts/reductedharmgmail.com/Booru_Bulk_Downloader

What It Does

A checkbox and a download arrow land on every thumbnail in a gallery. The checkbox adds an image to the batch — shift-click takes a range. The arrow grabs that one image's full-resolution original immediately. A draggable panel in the bottom-right corner holds the running count, Download selected, Save as .zip, Select all / Clear / Retry failed, and the filename options. Alt+D downloads the selection; Alt+A selects everything.

The Hard Part: Finding The Original

The thumbnail <img> is never the original, and every booru hides the original differently. The resolver works in three tiers, cheapest first, cached per post id:

DOM attribute — Danbooru puts data-file-url directly on the thumbnail. Zero extra requests.
Site JSON API — ?page=dapi&s=post&q=index&json=1&id=N (Gelbooru family) or post.json?tags=id:N (Moebooru family), returning file_url plus tags.
Post page HTML — fetch the post page and read og:image and the tag links. Universal, and needs no API key. This is the tier that saves you when a site starts demanding credentials.

Site support is a data array — host regex, item selector, id/link/original extractors, tag source, and API shape — so adding a booru is one object plus one @match line. Anything exposing a data-file-url-style attribute is handled by a built-in generic adapter.

Filenames Built From Tags

Template tokens: {{tags}} {{id}} {{rating}} {{site}} {{user}} {{md5}} {{ext}} — default {{tags}}__{{id}}. The extension comes from the real file URL, not the thumbnail. The sanitizer strips \ / : * ? " < > | and control characters, collapses whitespace, trims trailing dots, guards Windows reserved names (CON, LPT1), truncates on a tag boundary at roughly 170 characters, and suffixes _2 on collisions inside a batch.

Download Engine

GM_download first, for a real download-manager entry with the exact filename requested; then GM_xmlhttpRequest → blob → object URL → <a download>. A bare <a download> is deliberately never used on its own, because the attribute is ignored cross-origin and would simply navigate the tab. Concurrency is a limited pool (default 3), with per-item success/error state and a retry action.

What Was Verified, And What Was Not

Markup and APIs were checked against live sites rather than assumed:

safebooru.org — span.thumb > a > img.preview, tags already present in img[title]; dapi JSON fields confirmed.
konachan.net — ul#post-list-posts > li#p<id>, post.json?tags=id:N answered 200. This one exposed a real trap: the true original is a.original-file-unchanged → /image/…, while a#highres is only the converted /jpeg/ "larger version" and og:image is the /sample/. The selector list prefers /image/ accordingly.
Not verified live: Danbooru, Gelbooru.com and e621 — written from their published conventions, and they degrade to the HTML tier if the faster tiers miss.

Building it also caught a junk ? pseudo-tag from the tag-link scraper, an operator-precedence bug in the e621 id resolver, and a dead generic fallback.

Known Gotchas

Chrome blocks the second automatic download unless Automatic downloads is allowed for the booru host in site settings. GM_download dodges most of this, not all of it.
Gelbooru.com and rule34.xxx now require an API key for the dapi. Paste your api_key and user_id into the script's options, or let it fall through to the slower, key-free HTML tier.

Publication

Published in October 2026 to three hosts, each independently verified rather than assumed:

Greasy Fork — listing live, served file matches the release apart from the two @updateURL / @downloadURL lines Greasy Fork injects.
GitHub — Reduxed/booru-bulk-downloader, public, the canonical source.
OpenUserJS — served source confirmed byte-identical to the release, 44,970 bytes and 1,122 lines.

The OpenUserJS upload initially failed with 400 Selected file is not JavaScript. despite the correct filename and byte count. The cause was the multipart part type: the attached File reported text/plain because the staged resource used the default MIME. Staging it with a JavaScript MIME made the File report text/javascript and the upload went straight through. The bytes were never the problem.