Copyright © 2026 World Wide Web Consortium . W3C ® liability , trademark and permissive document license rules apply.
This
document
defines
the
concept
of
an
"image
resource"
and
a
corresponding
WebIDL
ImageResource
dictionary.
Web
APIs
can
use
the
ImageResource
dictionary
to
represent
an
image
resource
in
contexts
where
an
HTMLImageElement
is
not
suitable
or
available
(e.g.,
in
a
Worker).
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index .
This specification is not stable. Implementors who are not taking part in the discussions will find the specification changing out from under them in incompatible ways.
This document was published by the Web Applications Working Group as an Editor's Draft.
Publication as an Editor's Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.
This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document is governed by the 18 August 2025 W3C Process Document .
Web applications often accept developer-provided image resources to be displayed outside of a HTML document (e.g., in the OS, in the browser UI, etc.). This specification defines a WebIDL dictionary that describes an image, and where that image resource can be fetched from. The user agent can then use this extra information to choose an image that is best suited to display on the end-user's device or most closely matches the end-user's preferences or environment.
Fetching an image resource can reveal the user's IP address. It is RECOMMENDED that user agents fetch the chosen image resources when provided by the developer, and store them for re-use if needed. This limits tracking the user's location over time.
An image resource consists of:
link
's
sizes
attribute.
In
an
API,
an
image
resource
is
represented
as
an
ImageResource
dictionary.
In [ JSON ], image resource is represented as an object.
WebIDLdictionary ImageResource {
required USVString src;
DOMString sizes;
DOMString type;
DOMString label;
};
The
src
of
an
ImageResource
is
a
URL
from
which
a
user
agent
can
fetch
image
data.
The
sizes
member
is
equivalent
to
a
link
element's
sizes
attribute,
and
is
processed
in
the
same
manner.
When
multiple
ImageResource
dictionaries
are
available,
a
user
agent
MAY
use
the
sizes
value
to
decide
which
image
is
most
suitable
for
a
display
context
(and
ignore
any
that
are
inappropriate).
sizes
member
allows
for
multiple
space-separated
size
values
in
order
to
accommodate
image
formats
(such
as
ICO)
that
can
act
as
a
container
for
multiple
images
of
varying
dimensions.
const image = {
src: "path/to/image.ico",
sizes: "16x16 32x32 64x64",
type: "image/vnd.microsoft.icon",
};
some.
api
.
doSomething
(image);
The
type
member
represents
an
image
MIME
Type
for
the
image
resource.
A
user
agent
MAY
ignore
media
types
it
does
not
support.
There
is
no
default
MIME
type
for
an
ImageResource
.
The
type
is
purely
advisory.
User
agents
MUST
use
the
rules
for
sniffing
images
specifically
to
determine
the
computed
MIME
type
of
an
image
resource
.
The
label
of
an
ImageResource
is
a
string
that
provides
the
accessible
name
for
the
associated
image.
Implementors
MUST
derive
the
accessible
name
for
every
ImageResource
they
expose
to
users.
Authors
are
strongly
encouraged
to
add
a
label
unless
the
ImageResource
’s
accessible
name
can
be
inferred
from
an
external
label
in
its
context.
For
example,
in
the
context
of
a
manifest
,
the
name
(or
short_name
)
provides
an
external
label
for
all
members
of
the
icons
array
that
don’t
have
a
label
defined.
If
neither
an
explicit
label
nor
an
external
label
is
provided,
but
the
type
supports
providing
an
embedded
accessible
name
,
implementors
MAY
choose
to
defer
assigning
the
label
until
the
src
has
been
fetched
and
processed.
If
the
src
is
found
to
provide
an
embedded
accessible
name
,
implementors
MUST
update
the
label
to
match
that
value.
The
steps
to
process
an
ImageResource
from
an
API
are
given
by
the
following
algorithm.
The
algorithm
takes
an
ImageResource
input
.
It
returns
an
image
resource
.
src
and
base
URL
.
If
parsing
the
URL
fails,
throw
a
TypeError
.
sizes
member
is
present:
type
member
is
present
and
not
the
empty
string:
type
is
not
an
image
MIME
Type
,
throw
a
TypeError
.
type
.
To process an image resource from JSON , given a JSON Object input and a URL base . It returns an ordered map .
The
steps
for
fetching
an
image
resource
are
given
by
the
following
algorithm.
The
algorithm
takes
an
image
resource
image
,
and
an
optional
Request
request
.
,
and
an
optional
Mode
mode
(default
"
cors
").
It
returns
a
Response
.
cors
"
or
"
same-origin
".
undefined
:
The steps to derive the accessible name for an image resource resource are as follows. It returns a string .
Certain graphics formats support the inclusion of an embedded accessible name as part of the image’s contents. Examples include:
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY , MUST , and RECOMMENDED in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: