Responsive Image Pack — beta

Try it first: Create a responsive image pack from a synthetic image. No source-image upload is needed. Successful customer runs cost US$0.03 per source image, including platform usage.

Convert selected JPEG, PNG and still WebP images into a portable ZIP of responsive WebP and JPEG variants, with a manifest and relative srcset strings. No website crawling or arbitrary image-URL fetching.

See a real synthetic output

This preview uses the existing 1600 × 1200 synthetic gradient example, not customer images. The output below was extracted from its completed owner-test ZIP. No run is needed to view these images.

Original JPEG — 24,017 bytes	Generated WebP — 15,902 bytes

Both previews have the same 1600 × 1200 dimensions. Open an image to inspect it at full resolution; the page scales previews to fit.

Output dimensions	WebP bytes	JPEG bytes
480 × 360	2,242	4,951
960 × 720	6,652	13,385
1600 × 1200	15,902	24,882

These are actual file sizes for this one simple gradient, not a photo-quality benchmark or a guaranteed saving. The full-size JPEG output is larger than the original. Results depend on image content and encoding; inspect your own images and choose only the variants your layout needs.

Quick start

1. Upload your images to an Apify key-value store and keep its visibility Restricted. Note each exact record key; the display filename may differ from the stored key.
2. Select that store in Source key-value store, then enter Exact image record keys. The picker grants READ access to the selected store. The Actor uses Limited permissions and reads only your specified keys, without listing unrelated records.
3. Set the run's maximum charge to cover all requested images at US$0.03 each, then start the run. For example, 10 requested images require a maximum charge of at least US$0.30, even if some later fail validation.
4. Check the terminal run status and SUMMARY.json. Download OUTPUT.zip, extract it, and use its relative files in your project. Set HTML sizes to match your own page layout.

Example input:

{"storeId":"YOUR_SELECTED_STORE_ID","keys":["hero.jpg","product.png"]}

Missing input or {} runs a genuine bundled 32×24 synthetic PNG example. It produces two small image variants and is subject to the same successful-source price for customers.

For API use, inline mode accepts {"inline":[{"base64":"CANONICAL_IMAGE_BYTES"}]}. Use plain base64 without a URL or data-URL prefix. Do not combine inline and selected-store modes.

What you get

• OUTPUT.zip: generated image files, manifest.json and srcset.txt with portable relative paths.
• MANIFEST.json: dimensions, formats, sizes, generated filenames and per-source error codes.
• SUMMARY.json: requested, successful and failed counts, ZIP size and checksum. Its billingEnabled field describes configuration, not a payment receipt.
• Default dataset: one batch summary of counts and sizes, without source-store identifiers, input keys or download URLs.

Target widths are 480, 960 and 1600 pixels, clamped to the oriented original width and deduplicated. Images are never upscaled. Each successful source produces up to six variants: WebP and JPEG at up to three widths. Small images produce fewer variants. WebP preserves transparency; JPEG uses a white background. EXIF orientation is applied and metadata is stripped. Both formats use quality 82.

If some sources fail, valid peers can still produce a partial pack. Failed sources have error codes and are not counted as successful. If all sources fail, no successful pack is reported. Duplicate keys reject the input; identical content under different keys is detected and is not processed or billed twice.

Pricing

US$0.03 per successfully packaged source image, including platform usage, for up to six variants. There is no separate startup or dataset-item fee.

The maximum-charge preflight conservatively requires enough budget for every requested source. Only successful sources are charged, after the ZIP, manifest, summary and batch dataset row have persisted. Invalid, duplicate, failed and per-source-output-limited images do not incur the successful-image charge.

A later lifecycle failure can occur after outputs and a charge have been committed, so a failed terminal status does not necessarily mean no charge occurred. Do not resurrect an ambiguously charged run to force a retry; inspect the run's charge history first.

Live paid-customer charging remains unverified during this beta. Budget, successful-count and uncertain-response handling have been tested with injected metadata and mocked billing, without manufacturing customer activity.

Limits

All MB figures use decimal bytes.

• 1–50 source records per run.
• 10 MB and 24 million pixels per input image.
• 100 MB of downloaded image data and 300 million attempted metadata pixels per run. Applicable failed reads and decodes count toward these budgets.
• 20 MB generated-output budget per source, including a 100 KB reserve for metadata and ZIP overhead. Generated image bytes may therefore total at most 19.9 MB. An oversized source is excluded with SOURCE_OUTPUT_LIMIT; valid peers can still succeed.
• 100 MB maximum complete ZIP. Exceeding this global limit fails the whole run, rather than truncating it.
• Inline input: 5 MB decoded in total. Raw input JSON: 8 MB.
• Sequential processing with a 120-second application deadline.

These are product limits, not Apify's general platform limits. Animated images, including APNG, SVG, PDF and input archives are unsupported. Strict decoding may reject an image even when its extension or MIME type is allowed. Never enter passwords, API tokens or other credentials in input fields.

Privacy and retention

Source reads use only the selected store and exact keys. Outputs use generated filenames instead of input keys. Logs and the dataset do not expose input keys, source URLs, credentials or image bytes. The output images themselves still contain the pixels you supplied.

Treat any usable download link as a sharing capability. Do not publish links to private images. The Actor does not change store visibility or generate token-bearing links. Output availability and failed-run remnants follow the account's platform storage and retention settings; permanent availability is not promised. Fixed output names assume a fresh default store, so check the current run rather than relying on stale files from a resurrected run.

This is a beta, not a guarantee of visual quality, search indexing, demand, earnings or profitability. Long retention, repeated downloads and failed runs can affect operating costs.

Official guidance: key-value storage and Actor permissions.

How to prepare responsive product images without a CDN

A static storefront or product landing page can serve responsive images from its existing hosting. Prepare several image sizes ahead of time, upload them with your site, and let the browser choose among them. This workflow does not require an image-transformation CDN; you still need hosting for the exported files.

1. Start with a useful original

Choose a JPEG, PNG or still WebP you have permission to publish. Use a source large enough for your largest intended display, including high-density screens. Check the crop, product detail and background before converting. Responsive Image Pack Builder creates size variants, not new product photography or alternate crops.

The builder targets 480, 960 and 1600 pixels, without upscaling. A smaller original produces fewer distinct widths. For transparent products, inspect both formats: WebP preserves transparency, while JPEG has a white background.

2. Export, inspect and deploy

Follow the Quick start above to select exact image records from a restricted Apify store. After the run, check its status and summary, then extract OUTPUT.zip. Open the variants at their intended display sizes and compare fine detail, edges and backgrounds. Use the manifest to identify actual filenames, dimensions and successful sources before deploying.

Copy the image files to your site's public assets directory, preserving their relative structure or updating the paths. The ZIP is a preparation artifact, not a hosted image-delivery service. No website crawling or arbitrary image-URL fetching is involved.

3. Connect the files to your layout

Use <picture> to offer WebP with a JPEG fallback. Each w descriptor must match that file's actual pixel width. sizes describes the image's rendered width in your layout, not the source file's width. The browser also considers display density when selecting a candidate. See MDN's responsive-image guide and picture reference.

This illustrative square image fills the viewport up to 600px and occupies 600px on wider screens. Replace every filename with your exported paths, use your actual aspect ratio, and change both sizes values to match your CSS, including any page gutters. Only list variants that exist.

<picture>
  <source type="image/webp"
    srcset="images/product-480.webp 480w,
            images/product-960.webp 960w,
            images/product-1600.webp 1600w"
    sizes="(max-width: 600px) 100vw, 600px">
  <img src="images/product-960.jpg"
    srcset="images/product-480.jpg 480w,
            images/product-960.jpg 960w,
            images/product-1600.jpg 1600w"
    sizes="(max-width: 600px) 100vw, 600px"
    width="960" height="960"
    style="display: block; width: 100%; max-width: 600px; height: auto;"
    alt="Blue ceramic mug with a curved handle">
</picture>

4. Check loading on the actual page

Keep width and height proportional to the exported image so the browser can reserve space. Add loading="lazy" for images below the initial viewport; do not add it to the main above-the-fold product image. web.dev explains image loading and layout stability.

Test narrow and wide viewports and inspect the browser's Network panel for missing files and selected variants. Compare transferred bytes and visual quality on your own page rather than assuming a fixed saving or ranking improvement.

Try the synthetic example to inspect the output structure without uploading an image. The separate bundled example used with empty input {} has a tiny 32×24 source and demonstrates packaging, not full-size product-image quality. Successful customer runs cost US$0.03 per packaged source, including platform usage.