Break an Azure resource ID into its subscription, resource group, provider and the type and name pairs that follow. Nested resources keep their parents, which is the part that splitting on slashes loses.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Parse the ID. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Three type and name pairs after the provider. Splitting on slashes and taking the last two gets the container and loses which storage account it lives in.
/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Storage/storageAccounts/prodstorage/blobServices/default/containers/uploads
The subscription position is always a GUID. A name there means the ID was assembled by hand, and it is rejected wherever it is used as a scope.
/subscriptions/production/resourceGroups/rg1/providers/Microsoft.Storage/storageAccounts/acct
Resource group names may contain periods and must not end with one. It is easy to hit when generating a name from a domain.
/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/contoso.com./providers/Microsoft.Web/sites/app
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Everything after the provider is alternating type and name pairs, so that gets the child and silently loses which parent it belongs to.
Instead:Parse forward in pairs from the provider onward.
The GUID, the literal segments and the provider namespace are all case-insensitive to Azure, and different APIs return different casing. `resourceGroups` and `resourcegroups` both appear in real responses.
Instead:Compare case-insensitively, or normalise through the SDK's resource identifier type first.
The subscription position is always a GUID. A name or an alias there is rejected wherever the ID is used as a scope, and the error rarely says which part is wrong.
Instead:Take the ID from `az resource show` or the portal's JSON view.
An ID ending at the resource group is a resource group scope, and a role assigned there reaches every resource in it. The difference between that and a single resource is two segments.
Instead:Check where the ID stops before using it as a scope.
Each provider has its own naming rules. A storage account is 3 to 24 lowercase alphanumeric characters and globally unique, and a resource group must not end in a period.
Instead:Check the provider's naming rules separately. The ID structure being valid says nothing about the names inside it.
An Azure resource ID looks like a path and is not one. It is a sequence of alternating type and name segments, and parsing it as a path is where hand-written ID handling breaks.
Splitting on slashes and taking the last two segments gets the child and silently loses which parent it belongs to. Parse forward in pairs from the provider instead, and the structure comes out intact however deeply nested it is.
/subscriptions/{guid}
/resourceGroups/rg1
/providers/Microsoft.Storage
/storageAccounts/acct <- pair 1, the parent
/blobServices/default <- pair 2
/containers/data <- pair 3, the childThe subscription GUID, the literal segments and the provider namespace are all case-insensitive to Azure, and different APIs return different casing for the same resource. resourceGroups and resourcegroups both appear in real responses, so two IDs for one resource can compare unequal. Compare case-insensitively or normalise through the SDK's resource identifier type.
An ID ending at the subscription is a subscription scope, one ending at the resource group is a resource group scope, and one continuing into a provider names a resource. This matters for role assignments, where the scope decides how far down the grant reaches, and where a scope one level higher than intended is a common and quiet mistake.
/subscriptions/{guid} subscription scope
/subscriptions/{guid}/resourceGroups/rg1 resource group scope
/providers/Microsoft.Management
/managementGroups/contoso management group scopeIf that position holds a name or an alias, the ID was assembled by hand rather than read from the API, and it will be rejected wherever it is used as a scope. Take IDs from the tooling rather than building them from parts.
It parses the string. It does not call Azure, so it cannot tell you whether the resource exists, whether the provider namespace is real, or whether the type is spelled the way that provider spells it. Resource names have per-provider rules this page does not encode, because there are hundreds of providers and their rules change: a storage account name is 3 to 24 lowercase alphanumeric characters and globally unique, and nothing here checks that. It reports structure, scope and the parsing traps.