Export responsive images, HTML and a JSON manifest.

Use this export when you publish a static HTML site or maintain your own frontend. It includes actual resized image files and the data needed to reference them. You can inspect the local preview without installing a framework, then copy the markup or read the JSON during your build.

In the yaSEO workspace, select your images, review the filenames and alt text, and choose HTML + apps under Export for. Choose WebP or AVIF, a maximum width and a quality setting. The chosen format applies to all size variants in this export.

The files are ordinary web assets. You do not need an account connection, a yaSEO script on your site or a special player to display them. Keep the image directory with the exported markup while inspecting the package. When moving files into your project, update the paths to match the place from which your site serves public assets.

The exporter creates candidates at 480, 960 and 1440 pixels wide where those widths fit, plus the largest output allowed by your chosen maximum width and original file. Duplicate widths are removed. A 1200-pixel original exported with a 1600-pixel maximum produces 480, 960 and 1200-pixel files. A 320-pixel source produces one 320-pixel file.

Each variant is encoded from the source image. Smaller outputs are not created by repeatedly compressing an already compressed export. The aspect ratio is preserved and the original is never enlarged. The JSON records each file's actual width and height, so your build does not have to guess from its filename.

Free exports contain up to 3 selected source images and Pro exports up to 20. The additional width variants do not count as extra selected images. All files together must stay within the export's 30 MB encoded-output limit. If a package is too large, lower the maximum width, review the quality setting or select fewer sources.

<img src="images/01-green-backpack.webp"
  srcset="images/01-green-backpack-480w.webp 480w,
          images/01-green-backpack-960w.webp 960w,
          images/01-green-backpack.webp 1200w"
  sizes="(max-width: 1200px) 100vw, 1200px"
  alt="Green backpack with orange zipper pulls"
  width="1200" height="900" decoding="async">

The exported sizes value assumes an image that fills the viewport until it reaches its maximum exported width. That is a starting point for a full-width image. A card in a three-column layout needs a different sizes value. Adjust this attribute to tell the browser how wide the image is actually displayed, and keep responsive CSS such as max-width: 100%; height: auto.

The browser chooses a srcset candidate using the layout hint and display conditions. Listing smaller files does not force every device to use the smallest one. Inspect the chosen image URL in your browser when testing the finished page. The responsive images guide explains how sizes and srcset work together.

Generated markup includes width and height to describe the aspect ratio. It does not mark every image as lazy or high priority. Add lazy loading for suitable images below the initial viewport, and check the page's main visible image separately. A hero that contributes to Largest Contentful Paint should not be delayed by a blanket lazy-loading rule.

images.json has a schema name, version, package ID, destination and an assets array. Each asset includes its reviewed alt text, decorative flag, format, largest-file path, dimensions, size and checksum. The variants array contains the paths, dimensions, byte counts and checksums of every size. The srcset and sizes strings are included as conveniences.

Paths are relative to the export root. In a Vite or Next.js project, for example, you can put the images folder under public and reference /images/... from your rendered page. Update every variant path as well as the main file path. Do not assume the directory of the current page matches the directory of your assets.

Use your framework's normal rendering and escaping for descriptions. You do not need to inject the HTML string into a component. In React, the corresponding property is srcSet, while the JSON property is srcset. If your framework already generates its own responsive images, choose which system owns that step so you can predict the files visitors receive.

// After loading images.json into your build:
const image = manifest.assets[0];
const src = "/" + image.file;
const srcSet = image.variants
  .map(v => `/${v.file} ${v.width}w`)
  .join(", ");

<img src={src} srcSet={srcSet} sizes={image.sizes}
  alt={image.alt} width={image.width} height={image.height} />

All size variants of one image carry the same reviewed description in the manifest and generated markup. Marked decorative images use an empty alt attribute. The alt text is page markup, not metadata embedded into the WebP or AVIF file. Keep the JSON or CSV with the images when handing the package to another developer.

If you place the same asset in a different context, review the description for that placement. A product view and an editorial illustration can use the same photograph for different purposes. The export saves your current decision; it cannot determine the meaning of every future page.

Before deployment, open preview.html to check the files, inspect fine detail at the intended display size and test the real page at a narrow and wide viewport. Confirm that every image request succeeds, the selected sizes are sensible and the layout reserves room for the images. Exporting does not upload files to your host or deploy your application.

If you publish in WordPress and want the descriptions applied to Media Library items, use the separate WordPress export and importer. For a format decision, the WebP versus AVIF test lets you compare actual downloadable results.