How to Download Google Maps Photos in Bulk

If you want to download Google Maps photos for more than a handful of places, Google will not help you. There is no "export gallery" button on a listing, and the official Places API stops at ten photos per place. The practical route is to collect the photo links in bulk — one row per photo, tagged with the place it belongs to — and then fetch only the images you actually need. That is exactly what the Google Maps Photos Scraper does: you give it places or place IDs, and it returns every photo link it finds as a spreadsheet row.

The short answer, then: build or reuse a list of places, run them through a Google Maps photo scraper that returns links rather than files, filter the rows down to the photos that matter, and download those yourself. This guide covers why Google makes bulk download awkward, what the official API actually allows, what a photo export contains column by column, a step-by-step workflow, the jobs teams use it for, and the copyright question that photos raise and text data does not.

Why Google gives you no bulk download for Maps photos

A busy restaurant or hotel on Google Maps can carry hundreds of images: shots uploaded by the owner, photos attached to customer reviews, contributor uploads, interior and exterior views. In the Maps interface you can open them one at a time, and on some you can right-click and save. That is the whole toolkit. Nothing lets you take the gallery for a place — let alone for fifty places — and save it as a set.

That is a deliberate choice rather than an oversight. Most of the photos on a listing were not taken by Google, and many were not taken by the business either. They belong to whoever uploaded them, and Google displays them under its own terms. A one-click "download all" button would invite mass reuse of images Google does not own. So the product is designed for viewing, not exporting, and anyone who needs photos at scale has to work around that design.

The workarounds people try first are predictable. Saving images by hand works for one listing and collapses at ten. Browser extensions that grab every image on a page tend to pull only what has loaded on screen, mix in icons and map tiles, and lose the link between a photo and the place it came from — which makes the result useless the moment you have more than one location in the folder.

What the official Google Places API allows (and what it caps)

Google's sanctioned route is the Places API. A Place Details request can return photo references for a place, and a separate Place Photo request turns each reference into an image. Two limits make this a poor fit for bulk work:

• A maximum of ten photos per place. According to Google's Places API reference, a maximum of ten photos can be returned for a place. A listing with 150 images gives you the same ten-image ceiling as one with twelve.
• Every photo is a billed call. Photo requests are charged separately from the details request, at $7 per 1,000 calls on Google's Maps Platform pricing, on top of what you pay for the details lookups themselves.

For an app that shows a few pictures next to a place card, that is fine. For auditing a franchise, comparing storefronts across a city or building an image dataset, the ten-photo ceiling is the problem: the photos you most need to see are often the ones past the first ten.

How a Google Maps photo scraper works

A Google Maps photo scraper reads the same photo feed a visitor sees when they open a listing's gallery, and turns it into structured rows. The Livescraper version follows the same entry point as the rest of the Maps toolkit: you name the places, and the job returns what is attached to them.

Two design decisions are worth understanding before you run anything.

One row per photo, not per place. The output is a long table. If you submit 40 places and they average 60 photos each, you get roughly 2,400 rows, each tagged with the place it belongs to. That shape is what makes the data workable: you can filter, sort and count photos the same way you would any other dataset, and every row reconciles back to your input list.

Links, not image files. The scraper returns the photo links Google publishes for a place — not a zip of JPEGs. That sounds like a limitation until you work with it. Links are small, they join cleanly onto a place table, and you can render them in a spreadsheet or dashboard without storing anything. When you do need local copies, you fetch only the photos that survived your filtering, which keeps both storage and the licensing decision in your hands.

What you get back: the 16 columns of a photo export

Every row carries the same 16 columns, on every plan including the free tier.

Column	What it holds
query	The place you submitted, echoed on every one of its photo rows
name	The place name — filled when you submit a name or search, empty when you submit an ID
google_id	Google's feature ID for the place, the 0x…:0x… pair
place_id	The ChIJ… Place ID, your join key onto an existing place table
location_link	The Google Maps URL for the place, including coordinates
photo_id	Google's identifier for this individual photo — use it to de-duplicate across runs
photo_url	The link to the photo; one link per row
photo_url_big	The same photo at up to 2048×2048
original_photo_url	The thumbnail-sized variant, as served in the gallery grid
latitude, longitude	Coordinates of the place the photo belongs to
photo_date	When the photo was posted
photo_upload_source	Which Google app posted it and how — gmm_android, gmm_ios, and _review_post / _photo_post variants
photo_source_video	A video link when the entry is a video; empty on most rows
photo_tags	Google's gallery tags such as front, food or vibe
photo_tag_ids	The numeric IDs behind those tags

A few of these deserve a closer look because they change what you can do with the data.

Three sizes of the same image

original_photo_url is the small gallery thumbnail — right for a quick visual scan in a spreadsheet. photo_url is the default link. photo_url_big is the one to use when you need to judge detail: signage, the condition of a frontage, whether a menu board is legible. Pick the size per job rather than downloading the largest version of everything.

Date and upload source

photo_date lets you separate a current gallery from a historical one — the difference between "this is what the place looks like" and "this is what it looked like in 2019". photo_upload_source tells you whether a photo arrived attached to a review or as a standalone upload, which is a useful proxy for customer-taken versus deliberately posted images.

Tags and join keys

photo_tags and photo_tag_ids mirror the gallery tabs on the listing, so you can keep only storefront shots or only food photos without looking at a single image. And with place_id, google_id and photo_id on every row, the photos become an extra table hanging off your place list rather than a parallel copy of it. If the identifiers are new to you, our guide to Place IDs, CIDs and Google IDs explains how they relate.

When one photo per place is enough: the Maps scraper columns

Before you add a second tool, check whether the first one already covers the job. The Google Maps Data Scraper returns four image-related fields on every place row: photo_url (a link to one image of the place), photos_count (how many photos the place has in total), logo_url and street_view (a link to the Street View of the place).

For a lot of work, that is sufficient. A directory listing that needs one thumbnail per business, a CRM record that benefits from a picture, or a quick check that a location has any imagery at all — all of those are served by a single photo_url and the Street View link. Our field-by-field guide to Google Maps data covers these columns alongside the rest of the export.

Where it stops is breadth. A photos_count of 60 means 59 images you cannot see. The honest rule of thumb: start with the Maps scraper, and add the photos scraper when photos_count is the number you keep wanting to open.

How to download Google Maps photos in bulk: step by step

Here is the workflow to bulk download Google Maps images end to end, from an empty sheet to a folder of the photos you need.

1. Build the place list. Run the categories and areas you care about through the Maps scraper, or use the place IDs you already hold. Keep place_id and google_id on every row; these are what the photo rows will join back to. If you only need one known location, the free Place ID Finder gets you its ID.
2. Sort by photos_count. This tells you where the photo volume sits before you spend anything. A list of 300 places where a handful have 400+ photos will be dominated by those few.
3. Open the Google Maps Photos Scraper and add the places, or paste their place IDs.
4. Set the run parameters offered for the job.
5. Choose an output format — CSV, JSON or XLSX — and read the pre-flight estimate. It shows the row count and credit cost before the run starts, which matters here more than on most tools, because a place with 200 photos is 200 rows.
6. Run it and filter the export. Keep the tags, dates and upload sources that answer your question. Drop the rest.
7. Fetch only what survives. If you need local copies, download from photo_url or photo_url_big for the filtered rows, naming each file by photo_id so it maps straight back to its row.

A worked example

Say a regional chain wants to audit how its 45 locations look on Maps. The Maps scraper run shows a combined photos_count of about 3,100 — illustrative, but typical of a chain with busy sites. The first 500 rows on a new account are free, and the remainder at $0.002 per row comes to roughly $5. The export lands as one sheet; filtering on the front tag and on photo_date within the last two years cuts it to a few hundred storefront shots, which the operations team reviews from the thumbnails without opening Maps once. Old signage, a refurbished site still showing its previous fit-out, and a location whose top images belong to the tenant before it — all turn up in an afternoon.

What teams use Google Maps photo data for

Directory and listing sites

Directories want a picture next to every entry. For many of them, the single photo_url from the Maps scraper is all they should use — and before any image is displayed publicly, the rights question below applies. Where photo data earns its keep for a directory is behind the scenes: checking that a listing has imagery, choosing which places need their own photography, or confirming a business looks like the category it claims.

Real-estate and hospitality research

Property, retail and field teams evaluating sites at a distance get a lot from user-uploaded photos: the actual condition of a frontage, the car park, the interior, the neighbours. A listing description and a single hero shot both quietly omit these. Hospitality analysts use the same data to compare how hotels or restaurants in a market present themselves. Our posts on Google Maps data for commercial real estate and retail site selection cover the place-level side of that work.

Competitor visual audits

Photos are the first thing a customer sees in local results. Pull the galleries for every competitor in a category and city and you can see how you present next to them — often less flatteringly than anyone internally assumed. Pair it with the Google Maps Reviews Scraper: customers describe in words what the photos show, and reviews often name the thing the images are hiding.

Image datasets for vision models

Tagged, geolocated photos — storefront, food, interior, with coordinates and a category from the place table — are an obvious raw material for training or evaluating computer-vision models. The structure helps: tags give you weak labels, and photo_id keeps the dataset de-duplicated across runs. The rights exposure is highest here, though. Internal experimentation is one thing; training a model you distribute on images you have no licence for is a decision with real IP risk. Our piece on building an AI-ready business database covers the data-governance side.

Verifying a place is real and open

A listing with no recent photos, or whose newest images show a shuttered unit, is a signal worth checking before you send a sales rep or sign a lease. Sort photo rows by photo_date per place: a steady flow of recent customer uploads is good evidence that a business is trading; a gallery that went quiet years ago is a reason to look harder at its business_status in the Maps data.

Can you reuse photos you scrape from Google Maps?

This is where photos differ from almost every other kind of Maps data, and it deserves a plain answer. This is not legal advice — check with a lawyer for anything material.

The links themselves are public: Google shows them to anyone viewing a place, signed in or not, and collecting publicly visible references for research and auditing is long-established practice. The image behind the link is another matter. A photo on a Maps listing is usually owned by whoever took it — a customer, the business or a contributor — and holding a link to it grants you no licence to reuse it.

• Ordinary use: auditing your own locations, comparing storefronts internally, assessing a site remotely.
• Needs permission: republishing someone's photo on your website, in a directory entry, in an advert or in a sales deck.
• Real IP exposure: training a model you distribute on scraped images.

Google's terms also restrict automated access, so this is a terms question as well as a copyright one. Livescraper touches nothing behind a login, and exports auto-delete after 30 days. Our longer guide on whether scraping Google Maps is legal walks through access, contract, data protection and copyright separately. The short version for photos: a link is not a licence, so check before you reuse.

What it costs to scrape Google Maps photos

Pricing is per row, which here means per photo. Every new account gets 500 rows free, one time, with no credit card required. After that it is $0.002 per row — roughly $2 per 1,000 photos — pay-as-you-go with no subscription. Because photo volume varies so much between places, the pre-flight estimator is the number to read before every run; a small free-tier job against one representative location is the easiest way to calibrate. Full rates, including volume pricing, are on the pricing page.

Conclusion

Google does not offer a way to download Google Maps photos in bulk, and the Places API stops at ten per place, billed per photo. The workable approach is to collect the photo links instead: one row per photo, with the place, date, tags, upload source and three image sizes on every row, joined back to your place list by place_id and google_id. Start with the photo_url and photos_count you already get from the Maps scraper, add the Google Maps Photos Scraper when you need the whole gallery, filter hard, fetch only what you need — and treat every image as someone else's property until you know otherwise. You can create a free account and run your first 500 rows at no cost.

Related reading: How to Clean and Deduplicate Google Maps Data, How to Build a POI Database for Mapping Applications, How to Use Google Maps Reviews for Competitor Analysis.