How to Scrape Bing Image Search Results (2026)

I went looking for a clean way to scrape Bing image search results this month and hit the same wall everyone does: the official API is gone. Microsoft retired the Bing Image Search API on August 11, 2025, so there is no first-party endpoint that hands you image URLs anymore. What is left is the public results page, and Bing does not lay its image data out the way you would expect.

This guide is how to scrape Bing images in 2026 from that public page. I ran the code in July 2026, I show you exactly where the real image URLs hide, and I cover the block you will hit from a datacenter IP plus the two routes around it. You get runnable Python, a bulk-download shortcut, and a single-request scraper API example.

Is there a Bing Image Search API in 2026?

No, there is no official Bing Image Search API in 2026. Microsoft retired the entire standalone Bing Search family, Image Search included, on August 11, 2025. The lifecycle announcement states that existing instances “will be decommissioned completely, and the product will no longer be available to be used or new customer signup,” so the image endpoint stopped serving on that date and there is no new-customer signup to replace it.

The path Microsoft points you to is Grounding with Bing Search inside Azure AI Foundry, and it does not fit an image pipeline. It is built to feed live web data into an LLM agent, and Microsoft’s Grounding pricing page lists it at $14 per 1,000 transactions. You get a grounded text answer with citations, not a ranked list of image URLs and source pages as JSON.

That leaves scraping the public Bing Images page directly. Before you send a single request, it is worth knowing what Bing’s own robots.txt says about that path.

What does Bing’s robots.txt say about scraping image search?

Bing’s robots.txt disallows the image search path for every crawler. I fetched https://www.bing.com/robots.txt live in July 2026, and the catch-all User-agent: * block contains these lines among others:

User-agent: *
Disallow: /search
Disallow: /images/search?
Disallow: /images/search/?
Disallow: /images/searchbyimage

So the image endpoints you would scrape, /images/search? and its variants, sit under an explicit Disallow for the catch-all rule. robots.txt is a crawling convention rather than law, and it records Bing’s stated preference for automated access rather than a technical or legal barrier on its own. The US picture for public data leans toward scrapers, which I get to in the legality section below, but the practical takeaway is simpler: Bing has told crawlers to stay off /images/search, and it backs that preference up with the anti-bot behavior you meet the moment you request the page in Python.

How do you scrape Bing images with Python?

You scrape Bing images with Python by requesting bing.com/images/search, then parsing each result’s m attribute as JSON, because the real image URLs are not in the <img> tag. This is the detail that trips up most first attempts. The visible <img> in the grid carries a src that points at a small ts*.mm.bing.net/th thumbnail Bing hosts, not the original file. The full-size URL lives elsewhere.

Bing renders each image tile as an <a class="iusc" m="{...}"> anchor, and that m attribute is a JSON string holding the URLs you actually want: murl is the full-size image URL, turl is the Bing thumbnail, purl is the source page the image sits on, and t is the title. BeautifulSoup unescapes the attribute for you, so json.loads reads it directly:

import json, requests
from bs4 import BeautifulSoup

r = requests.get(
    "https://www.bing.com/images/search",
    params={"q": "coffee maker"},
    timeout=25,
)
soup = BeautifulSoup(r.text, "html.parser")

for a in soup.select("a.iusc")[:5]:
    meta = json.loads(a["m"])   # the m attribute is a JSON string
    print(meta["t"])            # title
    print(meta["murl"])         # full-size image URL (the original file)
    print(meta["turl"])         # Bing-hosted thumbnail
    print(meta["purl"])         # source page the image appears on

Every field you need for a dataset, the original image, a preview, and the page it came from, comes out of that one m blob per tile. There is no redirect to follow and no second request per image, which is the trap you hit scraping Bing’s organic web results where links are wrapped in bing.com/ck/a. Image tiles hand you the destination directly.

How do you page through more image results?

Bing returns roughly 35 image tiles per request, and you page deeper by passing a higher first offset. The first parameter is the index Bing starts the grid from, so stepping it by the number of tiles you got back walks you through the results:

seen = []
for offset in range(0, 140, 35):        # pages 1 through 4
    r = requests.get(
        "https://www.bing.com/images/search",
        params={"q": "coffee maker", "first": offset},
        timeout=25,
    )
    soup = BeautifulSoup(r.text, "html.parser")
    seen += [json.loads(a["m"])["murl"] for a in soup.select("a.iusc")]

print(len(seen), "image URLs")

That is the whole raw method: request the page, select a.iusc, parse m, read murl, and step first. It works until Bing decides your request looks automated, at which point soup.select("a.iusc") comes back empty. If you only need a folder of image files rather than structured metadata, there is a shorter route.

How do you download Bing images in bulk?

You download Bing images in bulk with the open-source bing-image-downloader library, which fetches the image files to a local folder in a few lines. It wraps the same public results page, resolves each murl, and writes the files to disk, so you skip the parsing entirely when what you want is images rather than metadata. It takes no API key and has no external dependencies, running on the Python standard library alone:

from bing_image_downloader import download

download(
    "coffee maker",
    limit=100,
    output_dir="dataset",
    adult_filter_off=False,   # keep SafeSearch on
    timeout=60,
)
# files land in dataset/coffee maker/

The trade-off is what you end up holding. The library downloads full image files, so you are storing copyrighted originals on your disk from the first run, where the parse-the-murl approach lets you keep just URLs and metadata and fetch files on demand. For a small training set that is fine; for anything you redistribute or keep at scale, the store-the-URL pattern is safer, and I come back to why in the legality section. Either way, both routes run from your own IP, which is where the blocking starts.

How do you avoid getting blocked when scraping Bing images?

You avoid getting blocked scraping Bing images by changing the IP reputation and the request rate, because those are what Bing scores, not your code. In my July 2026 runs the Python parse above returned tiles cleanly from a residential IP, while the same request from a datacenter IP came back with a challenge page and zero a.iusc tiles. Bing answers that block with an HTTP 200, so a status-code check passes while the image data is simply absent, the same quiet-block behavior I documented for scraping Bing without getting blocked.

These are the levers that actually move the result, in rough order of impact:

• Request from residential or ISP IPs. Datacenter ranges are the first thing Bing’s anti-bot flags on the image path. Route each request through a clean residential address so it presents as an ordinary home connection.
• Slow the request rate. Bing tolerates a steady, human cadence and punishes bursts with the challenge page. One request every few seconds per IP is a safer starting point than parallel floods.
• Pin the market. Without an explicit market, Bing localizes the image set to the exit IP, so a rotating proxy pool returns foreign-localized, non-reproducible results with drifting counts. Set the market so every call returns the same national set.
• Assert on the tile count, not the status. Treat an empty a.iusc list as a block and retry through a fresh IP. Trusting the bare 200 fills your dataset with empty pages.

Doing all of this yourself means renting a residential proxy pool, rotating it, detecting the challenge state, and pinning the market on every call. That is a maintenance project once you pass a few thousand images, which is why most teams hand the blocking to a scraper API.

How do you scrape Bing images at scale without managing proxies?

A scraper API removes the blocking work by taking your image query and returning parsed JSON, with the proxy rotation, the market pinning, and the m-attribute parsing handled server side. You send one request and get structured image results back, with no challenge page to debug and no thumbnail-versus-original confusion to untangle.

I use ChocoData for this. The call is a single GET to the bing/images endpoint with your query and an API key:

curl "https://chocodata.com/api/v1/bing/images?q=coffee+maker&api_key=$CHOCO_API_KEY"

The same request from Python, which is the version I run in pipelines:

import os, requests

resp = requests.get(
    "https://chocodata.com/api/v1/bing/images",
    params={"q": "coffee maker", "count": 50, "api_key": os.environ["CHOCO_API_KEY"]},
    timeout=30,
)
data = resp.json()
for img in data["results"]:
    print(img["position"], img["title"])
    print(img["image"])        # full-size image URL, murl already decoded
    print(img["source_page"])  # host page the image sits on (purl)
    print(img["source"])       # source domain, e.g. walmart.com

Each result comes back with image (the full-size URL), thumbnail, source_page, and source already mapped from Bing’s murl, turl, and purl, so there is no a.iusc blob to parse. Useful params: count takes 1 to 200 per call, first is the offset for paging deeper, country pins the market, and safe_search defaults to strict. The free tier covers 1,000 requests, which is enough to pull a few hundred images across several queries before you decide whether the managed route is worth it. If you would rather compare the managed options head to head, I rank them in best Bing scrapers and APIs in 2026.

Is scraping Bing images legal?

Scraping publicly visible Bing image results sits on firmer ground than scraping data behind a login, though the images themselves are a separate question. US courts have repeatedly found that accessing public web data is unlikely to violate the Computer Fraud and Abuse Act, most notably in hiQ Labs v. LinkedIn, where the Ninth Circuit held that scraping data open to the public is not unauthorized access. That covers the act of reading the results page.

The images are where care is needed. Each file stays under its own copyright regardless of how you collected the URL, which is why the norm is to store image URLs and metadata and fetch or display files on demand rather than rebuild a library of copyrighted originals. This is general information, not legal advice: you remain responsible for Bing’s terms, the source sites’ terms, and the copyright of each image. I go deeper on the rules in is scraping Bing legal.

What I would do

If I needed Bing image data tomorrow, I would not wait for the retired API to return, because it will not. For a quick, one-off dataset I would run the raw a.iusc parse from a residential IP, or reach for bing-image-downloader if I only wanted files in a folder. For anything ongoing across many queries and markets, I would send the query to a scraper API so my time goes to the data while the blocking and the murl parsing are handled for me. Start with ChocoData’s free tier and the single-request example above, then scale the query list once the JSON shape matches what you need.