Scraping images sounds simple — find the URLs, download the files. In practice, the modern web makes almost every part of that harder than it should be: galleries lazy-load on scroll, image URLs are signed by CDNs, the highest-quality version is hidden behind a hover state, and any site worth scraping has anti-bot defenses that will flag a naïve script within a few hundred requests.

This guide covers the actual methods that work in 2026, from one-off browser extensions to production-grade Python pipelines, plus the parts most tutorials skip: handling JavaScript-rendered content, working around hotlink protection, and the legal and ethical layer that’s getting harder to ignore.

Pick your method based on how much you actually need

There are roughly four tiers of image scraping, and the right tool depends on the volume, the target, and how often you’ll do it.

Tier 1 — One-time, small volume, single site. Use a browser extension or right-click and save. Anything else is overkill.

Tier 2 — Tens to hundreds of images from one site. A dedicated image extractor or a simple Python script that walks a single page.

Tier 3 — Thousands of images across many pages or sites. A real scraping script with proper rate limiting, retry logic, and storage.

Tier 4 — Continuous, large-scale collection (ML training data, ongoing market research). A production pipeline with rotating proxies, headless browser support, and a real data store.

Most articles on this topic conflate these. The right approach for tier 1 is genuinely different from tier 4, not just a smaller version of it.

Tier 1: Browser extensions

For grabbing a dozen images off a single page, browser extensions are still the fastest path. The ones worth installing today:

• Image Downloader (Chrome) — straightforward bulk download with filtering by dimensions and file type. The closest thing to a universal default.
• Imageye (Chrome, Edge) — similar feature set, good filter UI for size and format.
• DownThemAll! (Firefox) — long-running classic, still maintained, supports more file types than just images.

Avoid extensions that haven’t been updated in over a year (many of the “double-click downloader” tools from the 2020 generation are now abandoned or quietly malicious — Chrome’s extension store has been a graveyard for a while). Check the last update date before installing anything.

The limit of any extension: you’re still loading each page yourself. Past a few hundred images, your hand cramps.

Tier 2: Image extractors and headless tools

A step up from extensions: tools that take a URL and pull every image from the rendered page. Most are limited to one site at a time but handle the click-through work for you.

For one-off jobs, the simplest option is often just wget from the command line:

bash

wget -r -l 2 -A jpg,jpeg,png,webp,gif --no-parent https://example.com/gallery/

That recursively downloads images two levels deep from a URL, filtered to image file types. It’s been in every Linux distribution for 25 years and still works for static sites. For Windows, the equivalent is curl or PowerShell’s Invoke-WebRequest.

For sites where you’d rather not script, the no-code tools that have held up: Octoparse (still solid, freemium model), Apify (more developer-leaning, marketplace of pre-built scrapers including image-specific ones), Bardeen (newer, browser-extension-based, integrates with other workflow tools). ParseHub is no longer the obvious recommendation it was three years ago — the free tier has tightened significantly.

These tools handle pagination, basic JavaScript rendering, and CSV-style export. They start to break down on heavily defended sites or anything with infinite scroll behind a login.

Tier 3: Python — the working developer’s default

For real volume, write it yourself. The Python stack that works reliably in 2026 is short:

• requests — fetches pages and downloads image files
• BeautifulSoup — parses HTML and finds <img> tags and srcset attributes
• Playwright — drives a real headless browser when the site needs JavaScript to render images
• Pillow — processes downloaded images (resize, deduplicate, validate format)

The basic flow for a static page:

python

import requests
from bs4 import BeautifulSoup
from urllib.parse import urljoin
import os

url = "https://example.com/gallery"
headers = {"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)"}

resp = requests.get(url, headers=headers)
soup = BeautifulSoup(resp.text, "html.parser")

os.makedirs("images", exist_ok=True)

for img in soup.find_all("img"):
    src = img.get("src") or img.get("data-src")
    if not src:
        continue
    full_url = urljoin(url, src)
    filename = os.path.join("images", os.path.basename(full_url.split("?")[0]))
    with open(filename, "wb") as f:
        f.write(requests.get(full_url, headers=headers).content)

That’s the 30-second version. In practice you’ll need to handle a few realities:

• Lazy-loaded images live in data-src, data-original, or similar attributes rather than src — inspect the page before trusting the markup.
• srcset attributes carry multiple resolutions for responsive images. The highest-quality version often isn’t what src points to; parse srcset to grab the largest.
• JavaScript-rendered galleries won’t appear in requests output at all. Switch to Playwright, wait for the gallery to render, then extract from the DOM.
• Signed CDN URLs expire — if you collect URLs in one pass and download them later, expect 403s. Download as you discover.
• Hotlink protection rejects requests without the right Referer header. Pass the source page URL as the Referer and most of these go away.

For Playwright-rendered scraping:

python

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto("https://example.com/gallery")
    page.evaluate("window.scrollTo(0, document.body.scrollHeight)")
    page.wait_for_timeout(2000)
    
    image_urls = page.eval_on_selector_all(
        "img", 
        "elements => elements.map(el => el.src)"
    )
    browser.close()

That handles the scroll-to-load-more pattern that breaks naïve scrapers on most modern image galleries.

Tier 4: Production-scale collection

Once you’re past a few thousand images per run, or running collection jobs continuously (the most common case: building an image dataset for ML training, monitoring competitor visual assets, or curating content feeds at scale), the bottlenecks shift.

The script isn’t the problem anymore. The problems are:

Rate limiting and IP bans. Every meaningful site will block a single IP that hits it more than a few times per minute. The fix is rotating residential proxies — IPs assigned to real homes that look indistinguishable from normal user traffic. Datacenter proxies don’t work for this; major image hosts and e-commerce platforms flag datacenter IP ranges by default.

Geo-fenced content. Some images are only served to specific regions (licensed sports imagery, regional product photos). Country-level proxy targeting handles this; for genuinely localized content, city-level targeting matters.

Storage and deduplication. A run that pulls 100K images at 200KB each is 20GB. Hashing each image as you download (a simple hashlib.md5(content).hexdigest()) lets you skip duplicates without keeping a parallel filename database.

Retry logic. Networks fail, CDNs throttle, browsers crash. Wrap every download in retry-with-backoff, and log failures rather than dying on them.

Concurrency. Utilisation aiohttp with asyncio for download-heavy workloads. A naïve sequential script downloading 10K images at 200ms per request takes 33 minutes; the async version takes under a minute (assuming the source can handle it — don’t blow up someone else’s server).

For projects in this tier, proxy infrastructure matters more than the scraping script. The script is 100 lines you’ll write in an afternoon. Reliable, rotating, residential IPs are the part that actually decides whether the job runs to completion or stalls at 30% with the IP banned.

IPBurger fits here — rotating residential proxies, country-level targeting, sticky sessions when you need them — and the broader point holds regardless of provider: at this tier, the proxy layer is the load-bearing one.

The part most guides skip: legality and ethics

Image scraping is one of the legally murkier corners of web scraping, for a few specific reasons that have hardened over the past two years:

Copyright applies to images by default. Unlike text snippets, where fair use has more room, image reproduction is generally a copyright matter. The fact that an image is publicly accessible on the internet doesn’t grant a license to copy and redistribute it. For commercial use, this is a real risk; for ML training datasets, it’s an active and unsettled area of law.

Terms of service often prohibit scraping explicitly. Violating ToS isn’t usually a criminal matter, but it can be a civil one, and it can get your accounts and IPs banned. Read the ToS of any site you’re scraping at scale.

The EU AI Act and similar regulations are starting to require disclosure of training data sources for AI models. If you’re scraping for ML, document where the data came from and how it was collected.

Some content is off-limits regardless of technical accessibility. Images depicting identifiable private individuals, especially minors, are a hard no — even if the page is public. Privacy regulations (GDPR, CCPA) apply.

The practical heuristic: if you’d be embarrassed to explain your scraping operation to a judge or to the site’s lawyer, don’t do it. If you can explain it cleanly — “we’re collecting publicly listed product images for price comparison, respecting robots.txt, rate-limiting our requests, attributing sources” — you’re probably fine.

A reasonable default workflow

If you’re starting an image scraping project today and you’re not sure which tier you need, this is the path that scales:

1. Inspect the page in browser devtools. Find where the image URLs actually live. Static src? srcset? data-src? Background images in CSS? This 10-minute investigation saves hours later.
2. Try wget or a small requests + BeautifulSoup script first. If the images come down clean, you’re done.
3. If JavaScript rendering breaks it, move to Playwright. Headless browsers are slower but handle anything a real user can see.
4. If you start hitting 403s or 429s, add a residential proxy layer. Don’t try to outwit the anti-bot system by tweaking headers indefinitely; once a site has identified your IP, it’s identified.
5. Add deduplication, retry logic, and concurrency once volume justifies the complexity. Don’t build the production pipeline on day one.

Most image scraping projects die in the middle of step 4 — not because the scripting is hard, but because the operator tries to make datacenter IPs work where residential is required, burns three days on it, and gives up. Pick the right infrastructure from the start and the rest is straightforward.