---
title: "How to Search Azure Blob Storage by Name, Extension or Wildcard"
description: "Azure lists blobs by prefix only. How to find blobs by extension, wildcard or part of a name with az CLI, PowerShell, index tags and a GUI, with timings."
url: "https://jamsql.com/blog/2026-11-05-search-azure-blob-storage-by-name/"
html_url: "https://jamsql.com/blog/2026-11-05-search-azure-blob-storage-by-name/"
generated: "2026-11-02T21:30:33.185Z"
---

Published: 2026-11-02

# How to Search Azure Blob Storage by Name, Extension or Wildcard

Azure Blob Storage can only filter blob names by **prefix**. There is no server-side search for an extension such as `*.csv`, a word in the middle of a name, or a wildcard. So every way of finding blobs by name does one of two things: it lists all the names under a prefix and filters them on your side (the Azure CLI with `--query`, PowerShell’s `Get-AzStorageBlob -Blob '*.csv'`, AzCopy’s include patterns, a desktop client that scans), or it builds an index ahead of time (blob index tags, a blob inventory report, Azure AI Search). Azure Storage Explorer’s search box is a case-sensitive prefix filter, and the request to search by extension or wildcard has been open in its issue tracker since 2019. We timed the options on a container with 10,000 blobs on November 1, 2026: about 2 seconds to search all of it with most tools, 4.6 with the Azure CLI, and a fraction of a second once a prefix narrows the listing. Commands, numbers and the traps we hit are below.

## Why Azure can only search by prefix

Every listing goes through the [List Blobs](https://learn.microsoft.com/en-us/rest/api/storageservices/list-blobs) operation. Its only name filter is `prefix`, which “filters the results to return only blobs with names that begin with the specified prefix.” A `delimiter` (usually `/`) groups names into virtual folders, and each call returns at most 5,000 names, in alphabetical order with upper-case letters first, plus a marker for the next page. Newer service versions add `startFrom` and `endBefore` to bound a range of names, but those are ranges, not patterns. There is no suffix, contains or wildcard parameter.

That has two consequences for any tool:

-   **Searching a name pattern means reading every name under the prefix.** A container of a million blobs is at least 200 List Blobs calls, and each call is a billed list operation.
-   **A prefix is the only thing that makes it shorter.** Start from the deepest folder you can, or name blobs so that what you search for comes first (`2026/11/report.csv` rather than `report-2026-11.csv`, if you search by date).

## What Azure Storage Explorer’s search does

Storage Explorer’s blob editor has a search box and, since [version 1.16.0](https://github.com/microsoft/AzureStorageExplorer/releases/tag/v1.16.0) (November 2020), a filter panel with a *Prefix* field, renamed View Options in 1.21.0, where a *Flat* list mode shows every blob with its full name. All of them work through the service’s prefix filter. A Storage Explorer maintainer put it plainly in [issue #7987](https://github.com/microsoft/AzureStorageExplorer/issues/7987) (June 2024): “the server only supports case-sensitive prefix searching.”

The request to go beyond that is [issue #1667, “Search by more than just prefix (extension, wildcard, etc.)”](https://github.com/microsoft/AzureStorageExplorer/issues/1667). As of November 1, 2026:

-   It has been open since August 15, 2019, with 24 thumbs-up reactions and 20 comments, the milestone *Future* and the label *external* (“Root cause of this issue is in another component, product, or service”).
-   Seven related requests were closed as duplicates of it, among them [#2861](https://github.com/microsoft/AzureStorageExplorer/issues/2861) (“Search in subfolders”).
-   In April 2021 a maintainer [wrote](https://github.com/microsoft/AzureStorageExplorer/issues/1667#issuecomment-828000365) that it was “Not being developed at this time”, because “Without API support, implementing this would not be a very good user experience… We can only list blobs 5000 at a time”, and suggested prefix-friendly naming or blob tags instead.
-   On July 11, 2026 the issue was closed as not planned and reopened five minutes later. The latest release, [1.47.0](https://github.com/microsoft/AzureStorageExplorer/releases/tag/v1.47.0) (October 30, 2026), lists no change to search.

A separate request to make the search case-insensitive, [#1828](https://github.com/microsoft/AzureStorageExplorer/issues/1828), is also open. The maintainer’s reasoning is fair: a client-side search of a large container is slow. The measurements below show how slow, so you can decide whether it matters at your container size.

## Option 1: `az storage blob list` with `--query`

```
# every .csv in the container, at any depth
az storage blob list --account-name <account> --container-name <container> \
  --num-results "*" --query "[?ends_with(name, '.csv')].name" -o tsv

# names that contain a fragment
az storage blob list --account-name <account> --container-name <container> \
  --num-results "*" --query "[?contains(name, 'sku-0042')].name" -o tsv

# the server-side filter: everything under a folder
az storage blob list --account-name <account> --container-name <container> \
  --prefix exports/2026/ --num-results "*" -o tsv --query "[].name"
```

Three things to know, the first two of which changed our results:

-   **`--num-results` defaults to 5,000.** The [reference](https://learn.microsoft.com/en-us/cli/azure/storage/blob) says to provide `"*"` to return all. Without it, our `.csv` query returned 1,201 of the 1,241 lower-case `.csv` blobs, with nothing on standard error but `WARNING: Next Marker:` and a token. A script that checks only the output would not notice.
-   **The filter is case-sensitive.** `ends_with(name, '.csv')` skipped the 9 blobs ending in `.CSV`, and JMESPath has no lower-case function. For a case-insensitive match, print all names (`--query "[].name" -o tsv`) and filter them with `grep -i '\.csv$'`.
-   **It runs on your computer.** Microsoft’s [query guide](https://learn.microsoft.com/en-us/cli/azure/use-azure-cli-successfully-query): “Queries are executed client-side on the Azure CLI command’s returned JSON object”. The CLI turns every blob’s properties into JSON before the filter sees them, which is why it was the slowest option we timed (4.6 seconds for 10,000 blobs).

## Option 2: PowerShell `Get-AzStorageBlob -Blob`

```
$ctx = New-AzStorageContext -StorageAccountName <account> -UseConnectedAccount
Get-AzStorageBlob -Container <container> -Blob '*.csv' -Context $ctx

# or filter the full listing yourself
Get-AzStorageBlob -Container <container> -Context $ctx | Where-Object Name -like '*sku-0042*'
```

The [`Get-AzStorageBlob` reference](https://learn.microsoft.com/en-us/powershell/module/az.storage/get-azstorageblob) says `-Blob` “supports wildcards anywhere in the string”, while `-Prefix` “does not support using regular expressions or wildcard characters”, and the two sit in different parameter sets, so you cannot narrow a wildcard search with a prefix in the same call. With Az.Storage 9.7.2 on PowerShell 7.6, `-Blob '*.csv'` returned all 1,250 `.csv` and `.CSV` blobs, including those in virtual folders, in 1.7 seconds: it ignores case, and `*` matches across `/`. It still listed the whole container to do that; the pattern is applied after the listing. (We authenticated with the account key in our test; `-UseConnectedAccount` above uses your Entra ID sign-in and needs a data role such as Storage Blob Data Reader.)

## Option 3: AzCopy include patterns

[`azcopy list`](https://github.com/Azure/azure-storage-azcopy/wiki/azcopy_list) has no name filter. [`azcopy copy`](https://github.com/Azure/azure-storage-azcopy/wiki/azcopy_copy) has `--include-pattern`, which “supports wildcard characters (\*)” (for example `*.jpg;*.pdf;exactName`) and, per Microsoft’s [download guide](https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-blobs-download), applies “only to blob names and not to the path”, plus `--include-regex`. Adding `--dry-run` prints the paths it would copy without copying them, which works as a listing if AzCopy is what you have. That is our suggestion, not a documented recipe, and we did not time it.

## Option 4: blob index tags, if you can tag at write time

[Blob index tags](https://learn.microsoft.com/en-us/azure/storage/blobs/storage-manage-find-blobs) are key-value pairs that the service indexes, so [Find Blobs by Tags](https://learn.microsoft.com/en-us/rest/api/storageservices/find-blobs-by-tags) can search a whole account, or one container, without listing it. They help with names only when you plan for them:

-   Each blob carries at most 10 tags; keys are 1 to 128 characters, values 0 to 256, and both are case-sensitive.
-   The filter supports `=`, `>`, `>=`, `<`, `<=`, `AND` and `@container`. There is no wildcard or contains, so a tag such as `ext = csv` has to be set on every blob when it is written (the `x-ms-tags` header on upload, or Set Blob Tags later).
-   The index is eventually consistent, and Microsoft notes indexing can take up to 10 minutes under heavy load.
-   Tags are billed per tag per month.
-   Find Blobs by Tags “is not supported” on accounts with a hierarchical namespace (Data Lake Storage), where tags without indexing are in preview.
-   In the Azure CLI the search is `az storage blob filter`, part of the `storage-blob-preview` extension.

## Option 5: blob inventory or Azure AI Search, for large accounts

[Blob inventory](https://learn.microsoft.com/en-us/azure/storage/blobs/blob-inventory) writes a CSV or Apache Parquet list of every blob, daily or weekly, into a container you choose, optionally limited to up to 10 prefixes. You then search the report with whatever reads CSV or Parquet. It suits millions of blobs and questions that can wait: Microsoft says the first report can take up to 24 hours after you turn it on, and the scan is billed per million objects.

An [Azure AI Search blob indexer](https://learn.microsoft.com/en-us/azure/search/search-how-to-index-azure-blob-storage) keeps a searchable index that includes `metadata_storage_name` (the file name) and `metadata_storage_path`, and with `dataToExtract: storageMetadata` it indexes only names and properties, not content. It is a separate paid service, and it does not index blob index tags.

## Option 6: Find in Jam SQL Studio

Jam SQL Studio’s storage browser has had **Find** on its toolbar since version 1.5.4. It lists the names under the location and matches them in the app, the same way the tools above do, and shows the results in the grid while it scans. What you type decides the match ([docs](/docs/azure-storage/#find-by-name)):

Type

Finds

`invoice`

Names that contain *invoice*

`*.csv`, `report-202?.json`

Names that match as a whole; `*` is any run of characters, `?` one character

`reports/2026/*.csv`

A pattern with `/` matches the path below the search folder

`\*`, `\?`

A literal `*` or `?`

-   **Case** is ignored unless you press the **Aa** (Match case) button.
-   **Scope** is **This folder and subfolders** or the whole container. The toolbar’s prefix filter still applies when you search from the current folder, and a connection scoped to one folder never searches above it.
-   **Progress**: the bar shows how many names were scanned and how many matched. **Stop** pauses and **Continue** resumes where it stopped. The grid shows the first 1,000 matches, and **Load more** adds the next 1,000.
-   **Results** keep their full paths, and the row actions work on them as in the listing: download, preview, properties, delete, tier, SAS, copy and export. Virtual folders match too.
-   **Where it works**: blob containers, Data Lake (ADLS Gen2) containers and Azure file shares. A file share has no recursive listing, so Find lists it one folder per request.
-   **With Match case on**, a path pattern such as `exports/2026/*` sends `exports/2026/` to the service as the prefix, so only that folder is listed. Without Match case it cannot, because the service compares prefixes byte for byte, so it lists the whole scope.

AI agents connected through Jam SQL Studio’s MCP server get the same search as the `storage_find` tool. Find runs no faster than a script; the measurements show that the listing takes the time, whatever does the matching.

## What we measured

We created a container on a Standard general-purpose v2 account in Azure’s Poland Central region, uploaded 10,000 small blobs in a folder tree (5,600 logs under `logs/2026/MM/DD/`, 1,200 CSV exports under `exports/YYYY/MM/`, 2,000 images, 300 backups, 896 reports and 4 other files, with 1,250 names ending in `.csv` or `.CSV`), ran each search three times on November 1, 2026 from a Linux machine whose TCP connection to the blob endpoint took 36 ms, and deleted the container afterwards. Times are wall-clock ranges over the three runs; blobs per second is 10,000 divided by the median.

Method

Search

Listed

Time

Blobs/s

Found

List Blobs REST calls, no SDK (baseline)

none, listing only

10,000

1.90–2.00 s

5,100

–

Azure CLI 2.89.1, `--num-results "*"`

`ends_with(name, '.csv')`

10,000

4.64–4.73 s

2,150

1,241 (case-sensitive)

Azure CLI, `--num-results "*"`

`contains(name, 'sku-0042')`

10,000

4.59–4.70 s

2,150

2

Azure CLI, default `--num-results`

`ends_with(name, '.csv')`

5,000

2.50–2.61 s

–

1,201 (incomplete)

PowerShell 7.6.9, Az.Storage 9.7.2

`-Blob '*.csv'`

10,000

1.73–1.79 s

5,700

1,250

PowerShell, full listing

`Where-Object Name -like '*.csv'`

10,000

2.23–2.29 s

4,400

1,250

Jam SQL Studio Find

`*.csv`

10,000

2.18–2.36 s

4,500

1,250

Jam SQL Studio Find, Match case

`*.csv`

10,000

2.16–2.21 s

4,600

1,241

Jam SQL Studio Find

`sku-0042` (contains)

10,000

2.09–2.11 s

4,800

2

Azure CLI, `--prefix exports/2026/`

prefix only

600

0.82–0.93 s

–

600

PowerShell, `-Prefix exports/2026/`

prefix only

600

0.19–0.20 s

–

600

Jam SQL Studio Find, Match case

`exports/2026/*`

600

0.20–0.21 s

–

612 (600 blobs, 12 folders)

Jam SQL Studio Find, no Match case

`exports/2026/*`

10,000

2.08–2.11 s

4,700

612

How each was timed: the REST baseline is a short Python script that pages List Blobs with a container SAS and counts the names; the Azure CLI rows include starting `az` (0.13 seconds for `az version`); the PowerShell rows are `Measure-Command` around the call, with the module already loaded; the Jam SQL Studio rows were driven by a Playwright script in the desktop app, from pressing Enter in the Find bar until the status line said the search was done, including one click on Load more for the searches with more than 1,000 matches.

What the numbers say:

-   **The listing is the cost.** Every full search listed two pages of 5,000 names, and the REST baseline shows that took about 2 seconds from our machine. The rest is what each client does with the names: the CLI builds JSON for every blob, PowerShell builds objects. Matching 10,000 names in memory takes a negligible fraction of that.
-   **Results can show up before the scan ends.** In Jam SQL Studio the first matching rows appeared after 1.1 to 1.2 seconds, when the first page arrived; the Azure CLI prints nothing until it has listed everything.
-   **A prefix shortens every search.** Limiting the scan to the 600 blobs under `exports/2026/` took 0.2 to 0.9 seconds with any of them. Without Match case, Find could not send the folder as a prefix and scanned all 10,000 names for the same 612 results.
-   **Large containers scale with the page count.** At the roughly one second per 5,000-name page we saw, a million blobs would take on the order of three to four minutes to search by name with any of these tools. That is an extrapolation, not a measurement; for that size, a blob inventory report or an index is the better fit.

## Which one to use

-   **A one-off search in a script**: PowerShell’s `-Blob` wildcard, or the Azure CLI with `--num-results "*"` and the case-sensitivity caveat.
-   **The same attribute searched again and again**, on a flat account: blob index tags, set at upload.
-   **Millions of blobs, answers that can wait a day**: blob inventory.
-   **Browsing and acting on the results** (download, delete, change tier, generate a SAS): a desktop client that searches in place, such as Jam SQL Studio’s Find.

## Quick Answers

### Q: Can Azure Blob Storage search blobs by part of a name or by extension?

A: Not on the server. The List Blobs operation filters names only by prefix, so finding \*.csv or a word in the middle of a name means listing every blob under a prefix and filtering the names on your side. The alternatives are to index ahead of time with blob index tags, a blob inventory report or Azure AI Search.

### Q: Can Azure Storage Explorer search a container by file name?

A: Only by the start of the name. Its search box is a case-sensitive prefix filter, as a maintainer describes it in the Storage Explorer issue tracker. The request to search by extension or wildcard, issue #1667, has been open since August 2019; in 2021 a maintainer wrote that it was not being developed, because the service lists only 5,000 blobs at a time.

### Q: How do I list all .csv blobs with the Azure CLI?

A: Run az storage blob list --container-name <container> --num-results "\*" --query "\[?ends\_with(name, '.csv')\].name" -o tsv. Without --num-results "\*" the command lists only the first 5,000 blobs and prints just a Next Marker warning, so the result can be silently incomplete. The --query filter runs on your computer and is case-sensitive.

### Q: Does Get-AzStorageBlob support wildcards?

A: Yes, in the -Blob parameter: Get-AzStorageBlob -Container <container> -Blob '\*.csv' -Context $ctx. Microsoft's reference says it supports wildcards anywhere in the string. In our test it ignored case and matched blobs in every virtual folder. The -Prefix parameter does not accept wildcards, and the two cannot be combined.

### Q: How long does it take to search 10,000 blobs by name?

A: About 2 seconds in our test, because every client has to list all 10,000 names in two pages first. The raw List Blobs calls took 1.9 to 2.0 seconds, PowerShell 1.7 to 2.3, Jam SQL Studio's Find about 2.2 and the Azure CLI about 4.6. Narrowing with a prefix cut a 600-blob folder to 0.2 to 0.9 seconds.

### Q: Can blob index tags be used to search by file name?

A: Only if you store the part of the name you will search for as a tag value when each blob is written. Find Blobs by Tags compares exact values and ranges, with no wildcard or contains operator, each blob can carry at most 10 tags, and the operation is not supported on accounts with a hierarchical namespace.

## Sources and method

Service behaviour comes from Microsoft’s List Blobs, Azure CLI, Az.Storage, AzCopy, blob index tag, blob inventory and Azure AI Search documentation, and Storage Explorer’s state from its GitHub issues and release notes, each linked where it is used and read on November 1, 2026. The measurements ran the same day against a throwaway container on our test account, with the tool versions in the table. We have no usage numbers for Find to report; this post is about the method, not adoption.

## Summary

Azure Blob Storage filters names by prefix and nothing else, so searching by extension, wildcard or part of a name always means listing the names under a prefix and matching them on the client, unless you index ahead of time with blob index tags, an inventory report or Azure AI Search. Azure Storage Explorer’s search is a case-sensitive prefix filter, and the request to extend it has been open since 2019. In our test, searching 10,000 blobs took about 2 seconds with PowerShell’s `-Blob` wildcard or Jam SQL Studio’s Find and 4.6 seconds with the Azure CLI, whose default 5,000-result limit and case-sensitive filter both changed the answer. Starting from a prefix cut the time to a fraction of a second with every tool.

Last verified against learn.microsoft.com (List Blobs, Azure CLI, Az PowerShell 16.4 reference, blob index tags, blob inventory, Azure AI Search), the AzCopy wiki and the Azure Storage Explorer GitHub repository, and by the measurements above, on 2026-11-01.

### Related

-   [Find Blobs and Files by Name](/docs/azure-storage/#find-by-name)
-   [Azure Storage “Not Authorized” Errors](/blog/2026-09-30-azure-storage-permission-errors/)
-   [Azure Storage in Jam SQL Studio](/blog/2026-09-25-azure-storage-blobs-queues-tables/)
-   [Azure Storage Explorer Alternative](/alternatives/azure-storage-explorer/)
-   [Jam SQL Studio for Azure Storage](/databases/azure-storage/)

## Find Blobs by Name in Jam SQL Studio

**Find** on the storage browser toolbar searches blob containers, Data Lake containers and file shares by part of a name, an extension such as `*.csv` or a wildcard pattern, with or without matching case, in the current folder and below it or in the whole container. It shows how much it has scanned, lets you stop and continue, and every row action works on the results.

[Download Jam SQL Studio Free](/#download) [Find in the docs](/docs/azure-storage/#find-by-name)

Free for personal use • No account required • Mac, Windows, Linux

![Jam SQL Studio storage browser listing the folders and blobs of a container with size, last modified, tier and type columns](/images/docs/azure-storage-browser.png)