Extracting Images from Public URLs into a ZIP — Design Notes from Bulk Image Download

"Download all images from a webpage" sounds like a weekend script. In production it becomes a pile of edge cases: lazy-loaded assets, hotlink protections, CSS backgrounds versus <img> tags, huge galleries, and users who expect a ZIP instead of fifty browser download prompts. It also becomes an ethics case: public pages are not the same thing as permission, and login walls are not a boss fight for your crawler.

Bulk Image Download is my productized answer for the legitimate version of the job — paste a public URL, preview, select, ZIP — plus a set of browser-local extractors for files you already have. This post is about product boundaries and mechanics, not growth hacks.

Name collision, cleared up

People confuse two properties I run:

  • bulkimage.io — local-first batch image editor
  • bulkimagedownload.com — webpage/file image extraction into ZIP

Different verbs. Different trust models. The editor can stay fully local for core work. The URL downloader often needs server-side fetching to deal with CORS and hotlink quirks. That is exactly why credit accounting and public-page rules show up here and not in the editor narrative.

The happy path

  1. User pastes a public URL
  2. Service parses and lists candidates
  3. User previews and deselects junk
  4. Optional resize/convert/rename
  5. ZIP download (with free-tier size/count caps)

Up to thousands of images can be discovered per parse in the product limits; free ZIP output is capped more tightly so the free tier stays sustainable. Successful parses spend credits; failed parses should not. That single policy prevents a whole genre of frustrated mail about "I paid credits for a 404."

Why not "unlimited free"?

Because bandwidth, parsing, and abuse are real. Unlimited slogans attract scrapers that hammer targets you do not own and leave you paying the bill. A monthly credit allotment (100 on free) with a clear per-success cost (2 credits today for a successful URL parse) is intentionally dull — and fair.

Paid credits are for people who already know their volume. They are not a bait switch that appears after you fell in love with infinity.

Ethics as a product feature

I will be blunt in a developer forum:

  • Do not use this to bypass login walls, paywalls, or access controls
  • Do not treat public fetchability as a copyright license
  • Do not ask for features whose only purpose is unauthorized scraping

The product copy says public pages only for a reason. Preview-and-select is also an ethics assist: it slows down mindless "take everything" behavior and makes the user look at what they are packing.

If your organization needs provenance, keep the source URL with the ZIP. The tool should make extraction easy; your process should make attribution and rights review possible.

Server-side ZIP vs pure client fetch

Pure client fetching dies on CORS and hotlink rules constantly. Server-side retrieval and packaging often succeed where a browser tab cannot. The tradeoff is obvious: the service briefly touches image bytes to build your archive. The compensating controls are short retention (no long-term image archive) and user-driven selection rather than silent permanent storage.

That tradeoff is why I do not market Bulk Image Download as "100% local like the editor." Honesty about architecture beats a privacy slogan that would be false for URL mode.

Local extractors belong in the same family

Word, PDF, Excel, and similar files already sit on disk. Extracting images from them in the browser avoids an unnecessary network round trip and keeps those flows closer to local-first instincts. Same destination (a ZIP you control), different source constraints.

Implementation instincts

  • Separate discovery, selection, and packaging in the UI — conflating them creates irreversible mega-downloads
  • Show previews early so users drop tracking pixels and decorative chrome
  • Make credit costs visible before parse when possible
  • Fail politely on non-public or unreachable targets without inventing bypass tips
  • Cap free output sizes so one user cannot flatten the shared pool

A realistic CMS migration sketch

You are moving a public docs site. You have rights to the material. You paste section URLs, select diagrams, standardize filenames, and ZIP per section. Later you run those images through an editor if geometry or weight needs work. Downloader first, editor second — not the other way around.

What I optimize for

  • Legitimate public-page extraction with human selection
  • Predictable free-tier economics
  • Clear separation from the bulk editor product
  • No encouragement of unauthorized access

What I do not optimize for: stealth crawling, credentialed scrape recipes, or infinite free bandwidth cosplay.

Try it on a page you own or may use

Pick a public page you have rights to — your own marketing site is ideal. Run it through https://bulkimagedownload.com, deselect the junk, download the ZIP, and confirm the archive matches what you expected. If you needed folder editing instead, switch products rather than forcing the downloader to pretend it is an editor.

Useful tools are allowed to have edges. These are mine, written down on purpose.

Abuse, rate limits, and being a good neighbor

Any URL-fetching product will attract people who want to industrialize scraping. Product responses that matter:

  • Credits and caps that make blind mega-crawls annoying
  • Clear refusal to support authenticated targets
  • Short retention of fetched bytes
  • UI friction via preview/selection instead of one-click "steal site"

I would rather lose a user who wanted a weapon than keep a feature that turns customer bandwidth into someone else's denial-of-service hobby.

On the engineering side, treat target sites as neighbors. Respect reasonable failure modes. Do not retry aggressively on soft blocks. Surface errors that say "unreachable or blocked" without offering circumvention tips in the empty state.

Filename and format controls

Migrations die on naming. Allowing rename patterns and optional conversion before ZIP saves a second tool hop for many CMS imports. Keep originals available when fidelity matters; do not silently recompress as a clever default. Users who asked for originals will notice immediately — and they will not trust the next parse.

Observability for yourself as the operator

Watch parse success rate, credit burn, average selected-image ratio, and ZIP size distribution. If average selection ratio is tiny, discovery is too noisy. If ZIP sizes cluster at the free cap, users may need clearer upgrade messaging — or better selection guidance — rather than a higher silent limit.

Relating this to browser extensions

Extensions can read the current tab and sometimes see more of what the user already loaded. They also require install trust, update vigilance, and store review drama. A URL paste product trades some capability for a lower install barrier and a clearer server-side packaging path. I am fine with that trade. Power users with specialized needs can still write their own scripts; the product is for the legitimate middle.

A final boundary list (pin this)

  • Public pages only
  • Credits are capacity, not a license
  • No long-term image archive
  • Not a bulk editor (that is bulkimage.io)
  • No help bypassing authentication

If those boundaries match your use case, the tool will feel simple. If they do not, please use something else — including building an internal script under your own compliance review.

— Tom Wang