Component URLs

A component URL is a URL that locates a component, including its declaration, program, and assets. Component URLs are resolved to component declarations by a resolver.


The primary use of component URLs is to identify a component in the definition of a component instance, as part of a child declaration.

You should not use component URLs to identify component instances, as multiple component instances can share the same URL. For that purpose, instead use monikers.


A component URL can, in principle, have any scheme. Some common schemes you may encounter are:


A fuchsia-pkg component URL is a package URL that locates a component distributed in a Fuchsia package.

It has the same format as package URL, with a resource path relative to the package root that locates a component manifest. This path is usually of the form meta/<manifest_name>.cm.





A fuchsia-boot component URL locates a component in the system boot image. This scheme is used to identify components that must be resolved during early boot before a fuchsia-pkg resolver is available. It has the following format:





An http(s) component URL identifies a web page as a component. Such a component could be executed as a web page in a web runner, for example.


Relative URLs

The Component Framework supports a subset of relative URLs (Relative URLs are defined in URL RFC 3986). Specifically, Component Framework only supports relative URLs that are URL fragments. If a relative URL has any fields set other than the fragment then it will not resolve.

A relative URL is resolved at runtime based on the URL of the parent component's package. This allows component reuse between packages without creating additional manifests.

Relative URLs have the following format:




For a fuchsia-pkg parent component with the following URL:


The relative URL resolves to:


When should I use a relative URL?

Developers should use relative URLs when identifying other components in the same package as the parent component.

This pattern is often used in tests, where the best practice is to re-package production components in a test-specific package.