How to Download All the Images From a Page

Why the browser has no “save all images” button

You can right-click one image and save it. Do that forty times for a page of product shots or a gallery and the appeal of a single button is obvious. The browser does not have one.

The reason is partly that “every image on the page” is not a list the browser keeps lying around. It knows every <img> element it laid out, but it also loaded sprite sheets, tracking pixels, icons, avatars and a favicon, and it has no way to tell which of those you meant. A save-all feature has to decide what counts, and browsers have left that decision to extensions and to the person saving.

So the routes below are all “collect the images, then hand them over”, and they differ in three things: what they count as an image, whether the files stay on your machine, and whether you get the originals or a converted copy.

What actually counts as an image on the page

Every route inherits the same problem, so it is worth seeing it once.

Plain <img> elements are the easy case. They are in the page’s markup and anything can find them.

Responsive images are not one file. An <img> with a srcset lists several versions at different sizes, and the browser picks one “at its discretion” based on your screen and connection.[2] A tool that reads the src attribute gets whatever was loaded for your window, which may be the 400px version when a 2000px one exists at a URL right next to it in the markup. You did not pick that version, any more than you picked the format the image arrived in.

Lazy-loaded images have not arrived yet. loading="lazy" tells the browser to defer the image “until it reaches a calculated distance from the viewport”, so on a long page the images below the fold are still just an element with a placeholder.[2] Anything that reads only what has loaded will miss them. Scrolling the whole page to the bottom first is the fix, and it is a real step, not a detail.

CSS background images are not <img> elements at all. A hero banner or a tiled gallery thumbnail is often a background-image on a <div>, reachable only by walking the page’s computed styles.

Canvas and inline SVG are drawn, not loaded, so there is no file to grab without re-rendering them.

A route that catches more of these is doing more work; a route that catches fewer is faster and simpler, and may be all a given page needs.

Route 1: the extension’s batch save

Save Image As Type has a batch mode with two ways in.

The toolbar icon. Click it and the popup scans the current tab, resolving srcset and lazy images as it goes and skipping anything under 50 pixels on a side, then shows every image it found as a grid of thumbnails. Select all, or clear the selection and pick the ones you want; filter chips narrow the grid to one file type or to the large images only. Choose an output format, click Download selected, and every selected image is converted and packed into one ZIP called images-20260908-143205.zip. A progress bar tracks it and a Cancel button stops it.

The right-click menu. Right-click a blank part of the page, open Save Image As Type, then Save all images as…, and pick a format. This one skips the grid and runs on the whole page, up to 150 images per run. If the page has more, it saves the first 150 and tells you so.

The conversion runs in the browser through the Canvas API, so no image is uploaded. The archive is one download because a browser download API call downloads exactly one file, and forty separate save prompts is not a feature.[1] Each image keeps its own name inside the ZIP, which is the difference between a usable folder and one called image through image (149) - naming files as they save is the same problem one scale up.

What it costs you: every image comes out in the one format you picked. That is what you want when you came for JPGs and it is wrong when you wanted the originals exactly as they were. It also does not reach CSS background images or canvas drawings. For byte-exact originals, Route 2 or Route 3.

Route 2: save the page, keep the resources folder

Every desktop browser can save a page with its files. In Chrome, Edge or Firefox, press Ctrl+S (Cmd+S on a Mac), and in the save dialog choose Webpage, Complete rather than Webpage, Single File or HTML Only. You get an .html file and, next to it, a folder with the same name holding the page’s images, stylesheets, scripts and fonts.

The images in that folder are the originals, untouched, in whatever format the site served. Nothing is uploaded. It is built into software you already have.

What it costs you: you get everything, not just the images, so there is sorting to do afterwards, and the filenames are whatever the site’s servers used, which is often a hash. Images the page never loaded, because they were lazy and you did not scroll far enough, are not in the folder. Scroll to the bottom of a long page before you save it.

Route 3: DevTools, when you need to see exactly what loaded

For a technical reader who wants certainty about which files a page pulled, the browser’s developer tools give it directly. Open them with F12, go to the Network tab, filter to Img, and reload the page. Every image request is listed with its real URL, size and type. Right-click a row to open the image in a new tab and save it, or to copy its URL.

There is no one-click “save all” here, so for a large gallery this is slow. What it gives you that the other routes do not is a complete, accurate list of the image files the page actually fetched, which is useful when a route missed something and you need to know what.

A short console script does the bulk work for <img> elements:

// List the source URL of every <img> on the page.
console.log(
  [...document.querySelectorAll("img")].map((img) => img.currentSrc || img.src)
)

currentSrc is the version the browser chose from a srcset, which is the file you are actually looking at.

Route 4: wget, for a static gallery

If the images sit on a plain page with normal links, one command line pulls them:

wget --recursive --level=1 --no-parent \
     --accept jpg,jpeg,png,webp,gif \
     https://example.com/gallery/

wget follows the links it finds in the HTML and CSS it downloads and keeps only the files whose extension is on the --accept list.[3] It never touches a server other than the ones the page links to, and nothing is uploaded.

What it costs you: wget does not run JavaScript, so any image a script adds after the page loads is invisible to it, and modern galleries are mostly built that way.[3] It also cannot get past a login. It is the right tool for a static archive of images and the wrong one for a single-page app.

Route 5: a dedicated bulk image downloader, and how to vet one

There is a whole category of extensions whose one job is this: scan the page, show a grid, download the lot. Some are well made. The category also has a specific risk, and it is not hypothetical.

An extension that reads every image on every page you visit needs permission to read every page you visit. That is the same access the original Save Image As Type had when, with more than a million users, it was removed from the Chrome Web Store for injecting affiliate codes across 578 sites.[5] The pattern there was an established extension changing hands and the new owner monetising the audience, which no store listing warns you about.

Before installing one, the checks from the image converter extensions roundup apply directly: does it convert on your device or upload to a server, is every permission explained on a page you can read, is there a privacy policy that names things, and can you read the source. On that last point, note that a store listing declaring a data category is required “even when data is processed or stored locally”, so a declared category means the developer followed the rule, not that your images left the machine.[4]

Which route for which job

• You want a folder of JPGs from a gallery you are looking at: the extension batch save. It is the only route that also does the conversion, and the ZIP keeps the names straight.
• You want the original files exactly as served: Webpage, Complete, then pull the images out of the resources folder.
• You want to know precisely what the page loaded: the DevTools Network tab.
• You are archiving a static page and comfortable on a command line: wget.

If the images also came down in a format your editor will not open, the WebP to JPG walkthrough covers the conversion on its own, and the WebP problem end to end explains why the page served them that way and handed you URLs with no filename in them.