User guide

An image optimizer built with SvelteKit 5 and WebAssembly codecs. Your images are processed in the browser; they are not uploaded for encoding.

Supported formats

Input: JPEG, PNG, WebP, AVIF
Output (main encode): WebP, AVIF, JPEG, PNG, JXL
Output (responsive variants): WebP, AVIF, JPEG, JXL, PNG - any combination

All encoding runs via @jsquash WebAssembly codecs inside Web Workers - entirely in the browser.

Standard and Advanced interfaces

The Standard / Advanced switch in the app header changes how much control is shown for a single image. It does not change the encoder or create a separate copy of your settings: both interfaces use the same underlying recipe, so you can start in Standard and continue in Advanced without losing your selections.

Standard is the default. Use it when you want a complete responsive image set without configuring individual codec options. Use Advanced when you need comparison tools, crop, adjustments, analysis, manual resize rules, target-size encoding, or detailed codec controls.

Standard mode

Standard mode turns one source image into a ready-to-use set of responsive files:

1. Drop or browse for one image.
2. Choose one or more output formats: AVIF, WebP, JPEG, JXL, or PNG. The quality shown on each format comes from the selected compression preset.
3. Choose a preset:

4. Choose up to 8 output widths. Select Origin to include the source width, use a preset width, or add a whole-number custom width. Widths larger than the source remain unavailable unless safe upscaling is enabled in App Settings.
5. Optionally enter an output name, then click Create image set. If the master has not been optimised yet, Standard prepares it first and then creates every selected width/format combination.
6. Review the output ledger. Generated files show their actual sizes and can be downloaded individually.
7. Click Download set for a ZIP containing the generated images and supporting files.

Changing a format, preset, or width marks the set for an update. If some compatible files already exist, Standard reuses them and generates only the missing outputs. Selecting a preset changes compression values only; it does not clear the chosen formats or widths.

Switch to Advanced when you need crop, visual comparison, or manual controls. Advanced opens with the Standard format and quality choices intact. Returning to Standard reflects compatible Advanced changes as a custom recipe; creating a Standard image set clears any hidden Advanced resize rule so the selected widths are based on the uploaded source.

Advanced mode

Advanced mode exposes the full single-image workspace: before/after comparison, analyser, image information, adjustments, crop, presets, responsive variants, target-size encoding, codec-specific settings, and Delivery controls for metadata and filenames. The detailed sections below describe these controls.

The Standard / Advanced switch applies to the single-image workspace. Batch is a separate mode with its own shared recipe and multi-image controls.

Workspace state and documentation

The documentation button opens this guide in a separate browser tab. The optimizer remains open in its original tab, preserving the uploaded image, crop, previews, generated files, analysis, and in-memory worker state. Close or switch away from the documentation tab to return to the active workspace.

Uploading or replacing an image resets image-specific state-crop, analysis, previews, history, generated output, and any applied Analysis advice-and restores the selected Recipe as the clean processing baseline. App-level automation preferences remain unchanged. Settings intentionally saved in the Recipe are restored, so repeated jobs stay consistent without carrying unsaved, image-specific tuning into the next source.

Live Photos and animated sources

The optimizer accepts still images only. A JPEG with detectable Live Photo or motion-photo data, or a separate video companion supplied by the picker, is rejected before decoding. Turn off Live Photo or Motion in the Photos app before uploading, or choose/export a still image.

Animated WebP, animated AVIF, and APNG are rejected before processing because safely extracting a frame would first require decoding the multi-frame payload. Export or select a still version instead. HEIC and HEIF remain unsupported and must be converted to JPEG, PNG, WebP, or still AVIF first.

On iPhone and iPad, sources above 16 MP are rejected from their encoded header before pixel decoding. This limit applies on iPhone and iPad regardless of which browser opens IMPIB. Export a smaller still image before uploading; desktop sources retain their existing limits.

Advanced single-image workflow

Switch to Advanced, then drop one image.

1. The image decodes in a Web Worker and EXIF metadata is extracted in parallel.
2. Pixel analysis runs automatically. The optional SSIM quality search can also start automatically from Settings → App → Automation.
3. If Auto-generate on upload is enabled, every selected single-image target format is encoded. Otherwise, configure the targets and click Optimize.
4. The Optimize button reports the active work, for example Encoding AVIF… or Encoding WebP + JPEG….
5. The workspace source bar shows the filename, source format, dimensions, and original file size.
6. Adjust any setting and click Optimize again. Target-size mode searches quality independently for each selected format.
7. If encoding fails (for example because of memory pressure), the error remains visible and the Optimize action becomes available again. Use it to retry with the same source and settings without reloading the file.
8. Apply adjustments (brightness, contrast, saturation, warmth, sharpness, noise reduction) for a live preview without re-encoding-click Optimize when ready to bake them into the output.
9. Crop to select a region before encoding.
10. Generate responsive variants at multiple widths, then download individually or as a ZIP.

Batch mode

Drop multiple images (or switch manually with the mode toggle).

• Images encode in parallel using a worker pool limited by CPU cores, available memory information, selected codecs, and image resolution.
• Per-item status: pending → processing → done / failed.
• Drag pending or queued rows to change their Batch order. The gallery also offers sorting and filtering.
• Click any thumbnail to drill into a preview with comparison slider, metadata, crop, and per-item re-encode.
• Rotate/flip individual images from the preview toolbar: [ ↺ ] (CCW 90°), [ ↻ ] (CW 90°), [ ↔ ] (flip horizontal), [ ↕ ] (flip vertical). The transform is baked into the worker’s pixel cache and the image is immediately re-encoded.
• Failed items show a ↺ Retry button both on the gallery card and in the preview panel - retry re-queues the item with the current job settings without clearing the rest of the batch.
• WASM errors (including Unreachable code traps from concurrent WASM initialisation) are detected automatically - the failed worker is terminated, the warm pool is flushed, and the item is re-queued with a fresh worker after an 800 ms GC pause. Each item retries once; if it fails again, it’s marked as permanently failed.
• A permanently failed Batch item does not discard successful neighbors. Completed files remain individually downloadable, and retrying the failed item does not regenerate successful primary outputs. Image-set generation reports variant failures separately and preserves committed files in the streamed archive.
• Process new images encodes pending sources but never starts a download automatically.
• If responsive variant codecs are selected, Generate image sets prepares the requested widths after the primary images are complete.
• Download sets packages completed outputs only after the user explicitly requests delivery.
• The processing action changes to Cancel processing while workers are active.
• The trash action clears the Batch. It asks for confirmation when completed outputs have not been downloaded. Batch mode itself remains open.

ZIP folder structure

File naming

Standard keeps export intentionally simple: Output name optionally replaces the current source name. It is per-image input, is shared when moving between Standard and Advanced, and is never saved inside a recipe.

Advanced and Batch add a reusable Filename structure with a live result, custom token pattern, prefix, suffix, and date source. There are no built-in naming presets. Users can save their own structures and apply them later. The active structure is stored in the recipe; Batch also adds a stable item number to prevent collisions.

Custom filename patterns

Custom naming uses base-name tokens. Width, template identity, Batch collision identity, and the extension are added automatically where required, so do not type them into the pattern.

For example, [date]-[filename] produces the base 2026-08-27-hero. A responsive output becomes 2026-08-27-hero-1280w.webp, while an exact template becomes 2026-08-27-hero-open-graph.webp. The Export panel offers only tokens available in the current workflow. Unknown tokens are reported; an invalid pattern safely falls back to the original filename.

Use Save current to keep a naming structure for future images. Saved structures include the pattern, prefix, suffix, and date source. They remain available across sessions and can be applied to Advanced or Batch; applying one copies it into the active recipe, so later edits do not silently change previously configured recipes.

Folder structure

Every *-image-set.zip archive is itself the image-set container. There is no additional internal image-set/ wrapper, avoiding a redundant directory after extraction. Folder organization is automatic rather than a filename-preset or recipe choice:

• variants/ contains responsive outputs, grouped by width.
• templates/ contains exact-size outputs, grouped by template category.
• Supporting package files stay at the archive root. For a single-image set, the metadata report is named <image-name>_metadata.json.
• The file extension identifies the codec, so codec folders are unnecessary.

hero-image-set/
|-- variants/
|   |-- 640w/
|   |   |-- photo-640w.webp
|   |   `-- photo-640w.avif
|   `-- 1280w/
|       |-- photo-1280w.webp
|       `-- photo-1280w.avif
|-- templates/
|   |-- SEO/
|   |   `-- photo-open-graph.webp
|   `-- Social/
|       `-- photo-instagram-square.avif
|-- manifest.json
|-- photo_metadata.json
|-- srcset.txt
`-- picture.html

Batch keeps one source-name folder in the archive because different inputs can otherwise produce the same filenames. Duplicate source names are made deterministic (photo, photo-2, photo-3) rather than overwritten:

batch-image-set/
|-- photo/
|   |-- optimized/
|   |   `-- photo.webp
|   `-- variants/
|       `-- 640w/
|           |-- photo-640w.webp
|           `-- photo-640w.avif
`-- photo-2/
    |-- optimized/
    |   `-- photo-2.webp
    `-- variants/
        `-- 640w/
            `-- photo-2-640w.webp

Filename patterns control only the human-readable base name, not output identity or package structure. The app owns responsive width suffixes, template identity, codec extensions, and the required Batch index. For example, the base campaign-summer becomes campaign-summer-640w.webp or campaign-summer-open-graph.avif. This prevents ambiguous names such as photo (2).webp while preserving deliberate prefixes, suffixes, dates, indexes, and hashes.

In Advanced, Package contents controls these supporting files independently: metadata JSON, the asset manifest, and the paired picture.html + srcset.txt files. Batch offers the same switches under Export. Its ZIP places manifest.json at the archive root, metadata.json inside each source folder, and picture.html plus srcset.txt inside source folders that contain responsive variants. The markup uses paths relative to its own folder. Individual optimized-image downloads remain image files.

Long names are shortened safely when necessary. The extension and a stable identifier are retained, so the resulting ZIP remains portable across common operating systems. The Single Advanced download footer shows responsive, template, supporting, and total file counts before the ZIP is created. The same full-width footer shows planned counts and the Generate action while configuring an image set.

Export delivery settings

Open App Settings → Export to choose global package delivery behavior. Image formats, quality, dimensions, metadata embedding, and filename patterns remain part of the active Standard, Advanced, or Batch recipe.

Destination

• Browser Downloads is the default and works without folder permission.
• Selected local folder appears when the browser exposes secure directory access, primarily in current Chrome and Edge. IMPIB receives only the folder handle explicitly chosen by the user.
• Permission is requested by the browser when the folder is chosen or an export is saved. Unsupported, unavailable, or denied access falls back to Browser Downloads.
• Forget access removes the remembered folder handle. Selecting Browser Downloads can temporarily bypass a remembered folder without deleting that handle.

IMPIB never uploads an export and cannot browse arbitrary folders. Safari and Firefox use Browser Downloads because the required directory-picker capability is unavailable to the app.

Package contents

• Asset manifest adds manifest.json with generated dimensions, formats, sizes, and paths.
• Metadata report adds a JSON file with source and retained metadata where available. A single-image set uses <image-name>_metadata.json; Batch uses metadata.json in each source folder.
• Developer helpers add picture.html and srcset.txt when responsive outputs exist.

These global values seed each new image and newly started Batch. Advanced, Standard, and Batch can adjust package contents for the current job without changing the persistent defaults, image pixels, or encoded outputs. The next image or Batch starts from the latest App Settings values.

Saved recipes include package contents so a reproducible delivery workflow can override the App Settings defaults when it is applied. A later manual change affects only the current job and takes priority over the recipe. Destination folders and existing-file handling remain device-level App Settings and are never stored in recipes.

Existing files

For a selected local folder, Keep both adds a number when a requested filename already exists. Replace existing file writes to the requested name. Browser Downloads remain governed by the browser and operating system.

Batch Inspector

The Batch Inspector provides settings shared by every source in the current Batch:

Variant generation is inactive when no format row has Variants selected. When one or more rows are selected, the responsive-size controls become available and every chosen codec participates in the generated image set. The primary codec may also be selected for variants.

Custom variant widths can be added via the number input + [add] button. Custom widths appear as toggleable pills alongside the preset widths (320–2560).

Stale detection

Changing settings after encoding shows a “re-process” banner - but only for changes that affect encoded output:

Filename-only changes do not force the primary image to be encoded again. Variant selections may require the image set to be generated again, but they do not invalidate an otherwise compatible primary output.

Codec targets

Advanced mode can select one or more output targets. The primary target is the format displayed in the main preview; every checked target is included when you click Optimize.

• Each target row shows its configured quality and, after encoding, its actual size and savings.
• During a multi-format job, rows move through queued, encoding, and complete states.
• The Optimize button remains busy until all selected formats finish, including background work.
• Single-image auto-generation uses this same selected-target path.

Batch applies one primary format to every source. Responsive image sets may additionally contain any variant codecs selected in the format rows.

Codec-aware Batch workers

Batch processing chooses its worker limit dynamically from the user’s logical CPU cores, available device memory, selected codecs, and decoded image sizes. WebP and JPEG can use a larger worker pool on capable hardware; PNG uses a moderate limit, while AVIF and JXL use lower limits because their WASM encoders retain substantially more memory.

If responsive variants include additional formats, the most resource-intensive selected codec sets the safe worker ceiling for the complete Batch job. For example, adding AVIF to a WebP Batch lowers the limit to the AVIF-safe level; adding JXL can lower it further. Images above 4 MP consume additional concurrency capacity, with larger images using more of the worker budget.

Chrome and Edge provide an approximate deviceMemory value. Safari and Firefox do not, so the app uses fixed conservative memory policies rather than treating logical core count as a memory signal. Processor information may still help schedule CPU-safe codecs, but it never raises source-count, source-byte, decoded-dimension, or speculative worker-memory limits when memory data is unavailable. The Performance panel shows the active-worker count and codec-safe concurrency limit.

Image Analyser

After loading an image in Advanced mode, open the Analysis tab. Its views are Overview, Quality & Size, and Codec Advice. The Inspect tab contains the histogram and image details.

Automatic content classification

When an image loads, IMPIB analyses its pixels in the background and uses the results to suggest format and codec settings. The initial suggestions are estimates; use Measure to test actual encodes.

What it detects

Content types

Complexity levels

Recommendation card

The Overview view shows the selected format and quality, estimated savings or measured output where available, and a short explanation. You can apply the recommendation or make its format primary. The analysis also shows content and detail classifications.

Use Quality & Size to review the suggested quality for each format, apply a recommendation, or compare it with measured points. Codec Advice contains image-specific suggestions for individual encoder settings.

Codec advice explanations

The initial codec settings are stable, general-purpose defaults. Codec Advice does not replace those defaults globally: it recommends image-specific changes from the pixels in the current source. The info icon beside each recommendation explains why it was suggested; Learn more opens the matching topic below. Applying advice is optional and can be undone.

AVIF advice

WebP advice

JPEG advice

PNG and JPEG XL advice

Use case selector

Use the Optimising for menu to choose Web, Social, Shop, Archive, or Editorial. The choice influences format recommendations, quality steps, and the minimum SSIM used during measurement.

Changing the use case updates the initial recommendation. Existing quality measurements are marked stale because the use case changes the test ladder and quality threshold; use Re-measure to test that context.

Histogram

In Inspect, open the histogram view to see the tonal distribution. Toggle R, G, B, and LUM channels individually; at least one channel stays visible.

Pixel stats row

The histogram view also shows per-channel statistics such as entropy, standard deviation, minimum, maximum, and mean.

Measure quality and size

The initial recommendation is heuristic. Click Measure in Analysis to run real encodes and compare size and structural similarity (SSIM) with the source. Results appear in Quality & Size.

The search runs in a dedicated Web Worker using the current crop, resize, adjustments, and codec settings.

Quality ladder

The formats measured follow the selected output targets. Quality steps vary with image content and use case; PNG uses a single lossless step when included. A format’s ladder can stop early when it crosses the SSIM floor or meets a target size. AVIF uses the single-threaded encoder for each test.

Progress

While the search runs, Analysis shows progress and the number of completed tests. Cancel remains available.

Completed searches are saved locally in this browser’s IndexedDB. The cache keeps the 12 most recent image-and-settings combinations. Measuring the same file again with the same resize, crop, adjustments, codec options, selected formats, and use case restores those real measurements instead of repeating every encode. The Analysis panel keeps a Saved measurements label visible, and a brief completion message confirms that saved analysis was loaded. Changing the use case or image settings marks the results as stale and identifies what must be measured again.

Measured results

The Overview view compares the selected format with the measured recommendation. In Quality & Size, choose a format to see its measured quality steps, file sizes, SSIM values, and differences from the suggested step. Apply a measured step to use that quality. The SSIM value ranks these tests under IMPIB’s measurement method; it is not directly comparable with SSIM values from other tools.

Encode at target file size

Compression results depend on the image’s actual content-not only its original file size or the quality value you select. Large, smooth areas and repeated colours are usually easier to encode than fine texture, noise, foliage, grass, architecture, and many sharp edges. Dimensions, source format, metadata, and the selected codec also affect the result.

For example, a 10 MB coastal photograph containing mostly smooth blue sky and sea with a small area of land might compress to roughly 200 KB. A 4 MB photograph containing detailed forest, grass, and buildings with only a little sky might still be around 600 KB at the same quality setting. The precise numbers will vary, but the important point is that a smaller source file does not guarantee a smaller optimized output, and identical quality values do not produce identical file sizes.

This is where Target file size is useful. When a website, marketplace, upload form, or delivery budget requires a specific maximum size in KB, set that limit and let the optimizer search for the highest quality that fits it instead of guessing with the quality slider.

In Advanced mode, prepare the image first: choose formats, crop or adjust it if needed, and set the standalone Output size. Then choose Optimization goal → File size and enter the maximum in KB. Presets provide common 100 KB, 250 KB, 500 KB, and 1 MB limits, and the workload summary shows the selected format count, maximum number of tests, and sequential execution policy. The same maximum is applied independently to every selected format.

For example, selecting AVIF, WebP, and JPEG with a 250 KB target asks the app to find the highest quality AVIF, WebP, and JPEG that each fit at or below 250 KB. The Optimize button reports each format as it is searched.

File Size is a dedicated standalone-output workflow:

• Quality sliders remain unchanged but are ignored while the target is enabled.
• WebP or JXL Lossless is temporarily overridden because a quality search requires lossy encoding.
• PNG remains lossless. The app applies its strongest compression, but PNG may exceed the requested maximum when the pixels cannot be represented within that budget.
• Crop, Adjust, rotation, format selection, and output geometry lock while the search is running so every test uses identical pixels.
• The lower Variants tab becomes Target results. It does not offer responsive generation in File Size mode.
• Turning File Size off returns optimization to the configured quality and lossless settings and restores the normal Variants workflow.

Responsive variants are deliberately separate. They are generated directly from the prepared source at several dimensions; every dimension produces a different byte size. A 250 KB standalone result is therefore neither the source for those variants nor a promise that every responsive file will also be 250 KB.

How binary search quality works

With normal optimization, you choose a quality value and the app encodes the image once. The visual quality is predictable, but the resulting file size is not. With a target-size encode, you choose the maximum file size instead. The app must then discover which quality value gives the best result without crossing that limit.

Binary search is an efficient trial-and-narrowing method. Instead of testing every quality value from 1 through 100, the optimizer first tests the middle of the available range. Based on whether that result is too large or fits, it discards the unsuitable half of the range and tests the middle of the remaining half. Repeating this process quickly closes in on the highest usable quality.

This is not a different compression codec or an AI estimate. It repeatedly uses the selected codec to produce real files and measures their actual byte sizes. Consequently, target-size encoding is slower than a normal single encode, but it can provide a predictable size ceiling for supported lossy formats when the image can fit the requested budget. Each selected format is searched separately because, for example, quality 70 in AVIF is not equivalent to quality 70 in JPEG and the formats produce different file sizes.

There is no formula to predict what quality value will produce a given file size - it depends on the image content, dimensions, and codec. So the worker uses a binary search over the quality range to find the answer empirically:

1. Start with the full quality range: low = 1, high = 100.
2. Pick the midpoint: mid = (low + high) / 2.
3. Encode the image at quality mid.
4. If the encoded file fits within the target size → save it as the best result so far and search higher (low = mid + 1) to see if better quality still fits.
5. If the encoded file is too large → search lower (high = mid - 1) to reduce quality.
6. Repeat for up to 10 iterations. The search often converges earlier when no untested quality remains.
7. Return the best result found. If nothing fits even at quality 1, quality 1 is used as a last resort.

The result is the highest quality found by the search that fits the budget, when a fitting result exists. File size does not always change monotonically with the quality setting, so treat it as a measured best effort rather than a mathematical optimum.

Format-specific behaviour:

• WebP / AVIF / JPEG / JXL - each selected format is searched independently over its quality range.
• PNG - PNG has no lossy quality axis. The strongest lossless compression is used as a best-effort result, with no guarantee that it will meet the maximum.

Progress, results, and downloads

While processing, Target results shows the active format and its real search step. Search history records each attempted quality, resulting file size, and whether it fitted the maximum. These are actual encode measurements, not estimated progress. Search history stores numbers only, not a copy of the image for every attempt.

Completed formats remain available if a later format fails. After processing, each result row shows the resulting quality, actual size, difference from the budget, real test count, encode time, and one of:

• Target met - the output is within the maximum;
• Over limit - even the lowest tested lossy quality could not meet it;
• Best effort - a lossless format such as PNG could not meet it.

Use a row’s Compare action to inspect that format against the prepared source, its Download action for one format, or Download all target results for a ZIP containing the completed standalone outputs. A failed format offers Retry without discarding completed results. The app prepares the ZIP one result at a time to limit temporary memory use.

Changing the byte budget, codec settings, dimensions, crop, rotation, adjustments, or export policy marks affected results Outdated. Outdated files are excluded from the combined ZIP, and Target Results offers a full re-run so every downloaded file matches the visible configuration.

Performance and memory cost

Each binary search iteration is a full encode, so a target-size search can take substantially longer than one fixed-quality encode. The cost depends on the image, format, device, and number of tests completed.

Selected formats are searched one at a time. This is intentional: AVIF and JXL workers can retain large WASM heaps, and running several searches simultaneously can freeze or terminate a browser tab, especially on iPadOS. The app keeps completed current-run outputs available, retains only the best candidate from each search, and clears target results and object URLs on reset or source replacement.

Responsive variants

Generates your image at multiple widths and formats for use in <picture> / srcset markup.

Standalone output size and Image set sizes are independent. Standalone output size controls the individually optimized file. Responsive widths and exact-size templates are generated directly from the uploaded source, not from that resized standalone output. For example, an Exact 200 × 200 standalone file can be produced alongside 320w, 640w, and 1200w variants when the uploaded source is at least 1200 pixels wide.

In Standard, formats, widths, generation, individual downloads, markup copying, and ZIP export are combined into the Create your image set workflow described above. In Advanced, use the image-set panel for the more detailed workflow below.

Workflow

1. Open the image-set panel and its Generate view.
2. Choose up to 8 responsive widths, including Origin, preset widths, or a custom width. Add exact-size templates if needed.
3. Select the desired variant codecs in the format controls. Batch can also use variant codecs different from its primary codec.
4. Optimize the primary image if prompted, then click Generate set. Widths larger than the source require Allow safe upscaling in App Settings and remain subject to browser-safety limits.
5. Open Download to get individual files or select Download image set for the ZIP.

Responsive markup and exact-size templates

Copy picture set and Copy srcset produce responsive-width markup. They become available only after at least one responsive variant has been generated in a supported format. Exact-size template outputs are exported as files and recorded in the manifest, but they are deliberately excluded from responsive srcset markup because differently shaped images cannot share width descriptors safely.

The copy actions remain unavailable when:

• only exact-size templates have been generated;
• no responsive widths are selected; or
• every selected responsive width is skipped because safe upscaling is off or the requested enlargement exceeds the safety limit.

Select and generate at least one eligible responsive width to enable the markup actions. Exact-size templates can still be downloaded or exported while those actions are unavailable.

Exact templates and source upscaling

Exact templates request a fixed width and height, such as Instagram Story 1080 × 1920. The template catalogue compares those requirements with the uploaded source dimensions. The standalone output resize setting does not limit exact templates or responsive variants.

Catalogue filters have distinct purposes:

• Best fit shows templates that use a recommended selected format, need no source upscaling, and retain at least 90% of the image with Cover or occupy at least 90% of the canvas with Contain. The complete catalogue labels lesser matches as Good fit, Crop needed, Padding needed, Format alternative, Needs upscaling, or Unavailable.
• Selected shows the current template choices, and All restores the complete catalogue.

Fit describes technical framing and compatibility, not image meaning. Platform metadata such as Popular remains separate because the app cannot infer from dimensions alone that a photograph is a logo, product image, profile picture, or other specific asset.

Social and E-commerce add a second platform row. Social can be narrowed to Instagram, Facebook, LinkedIn, or X; E-commerce can be narrowed to Shopify or Amazon. These platform controls combine with search, Selected, and Best fit rather than replacing them.

Built-in template coverage

Every built-in category contains a practical set of outputs:

The web-icon presets are raster PNG fallbacks, not substitutes for an SVG master. Chromium’s web app guidance calls for 192×192 and 512×512 manifest icons, while Apple documents a 180×180 PNG touch icon. The favicon preset uses the 32×32 PNG output shown in Shopify’s Liquid reference.

Sources: web app manifest icons, Apple touch icons, and Shopify favicon output.

Wallpaper entries are convenience canvases based on common display resolutions, not platform upload requirements. Editorial dimensions are exact RGB pixel calculations for 300 PPI. IMPIB does not convert images to CMYK, embed press colour profiles, add bleed, or create press-ready files. Choose the matching physical size, perform colour conversion, and complete preflight in a print-production application because the pixel file alone does not force a paper size.

Use Create template for client-specific or internal output sizes. Name it and enter the exact width and height; the optional Organize section places it in an existing or new category and subcategory. Custom templates are stored in this browser and can be edited, duplicated, or deleted. A saved recipe embeds any custom templates it uses, so exporting the recipe carries those definitions to another computer.

When the source is too small, the template remains selectable but shows:

• a warning marker beside its title;
• the dimension below the minimum and the required value; and
• skipped-source too small in the applied-template list.

Allow safe upscaling is an application-level policy in Settings → App. It is shared by standalone outputs, responsive variants, and exact-size templates, and is off by default. The workspace reports when enlargement is active or required without changing this safety preference. While it is off, a template larger than the effective source is excluded from the generation plan. It does not count as a planned, missing, or failed output. Eligible responsive widths and exact templates continue generating normally.

Enable Allow safe upscaling only when producing the requested dimensions is more important than avoiding enlargement. The browser then resamples the source with the selected algorithm; this cannot create additional source detail and may reduce perceived sharpness.

Responsive widths larger than the source are generated only when safe upscaling is enabled. Batch first generates all native and downscaled widths using its normal parallel worker pool. It then revisits only images requiring enlargement and processes only those widths sequentially. Accepted targets can be up to 4× and 32 megapixels; targets above either limit are skipped and reported as unsafe, preventing a large resize from exhausting browser memory. In Batch Overview, every enlarged width includes an ↑ N× marker showing its enlargement relative to the effective source width; the full source and factor are also available in its description.

For memory-intensive Batch variants, the app releases the previous encoder before starting the next image. If an encoder reports a recoverable failure, that image is retried once with a fresh encoder; if it fails again, the image is marked as failed instead of stopping the rest of the Batch. In browsers that expose memory-pressure information, a new intensive encode is also stopped when pressure remains critical after cleanup. A browser can still reload the page if its operating system ends the process before the app receives an error, so the 4×/32-megapixel limits remain the main protection.

While variants are being created, Batch progress represents requested format-and-width outputs-not only uploaded image count. Expand an image and open Overview → Variants to see the codec and width currently being encoded. All selected codecs remain visible in a steady row, with only the active codec highlighted.

Advertising templates

The Advertising catalogue includes:

• Google responsive image assets in landscape, square, and vertical formats;
• common desktop display placements such as Medium Rectangle, Large Rectangle, Leaderboard, Wide Skyscraper, Half Page, and Billboard; and
• mobile banners and portrait/landscape interstitials.

Existing Facebook, Instagram, LinkedIn, and X templates also carry advertising search tags, so searching for ad or sponsored finds reusable social placements without creating duplicate dimensions.

Advertising templates currently recommend JPEG for broad upload compatibility. PNG remains available when a lossless output or transparency is more important than file size.

Adaptive variant quality

Adaptive variant quality is enabled by default in the image-set controls. It applies a small amount of additional compression as outputs become smaller, while the largest selected width keeps the exact configured quality.

The base quality is always the codec’s current quality setting. The app does not distinguish how that value was chosen, so adaptive variants work consistently when the base came from:

• The initial app default or an applied preset
• An Analyzer recommendation that the user applied
• A manual quality-slider adjustment

Each output format keeps its own independent base. For example, AVIF Q40, WebP Q70, and JPEG Q74 remain separate starting points; quality numbers are never translated directly between codecs.

The reduction is calculated from three inputs:

1. Relative dimensions - the largest selected width receives no reduction. The reduction increases logarithmically as a variant becomes smaller and reaches its limit at an 8× width reduction.
2. Current base quality - at most approximately 7.5% of the current quality may be removed, with an additional safety cap per codec. An already aggressive quality setting therefore receives a smaller absolute reduction.
3. Image content - the existing pixel Analyzer measures edges, sharpness, noise, and smoothness. Detailed or noise-heavy images retain more quality; smooth images allow more reduction.

For a smooth image with 1920px as the largest selected output, representative results are:

Detailed images receive smaller reductions than these examples. Disable Adaptive variant quality when every width must use an identical quality value.

Adaptive quality does not run a quality search, create comparison encodes, or add an SSIM pass. The calculation only changes the quality value supplied to the encode that was already required for each width and format, so its processing overhead is negligible.

An optional metadata report can be included through App Settings → Export → Metadata report or the active Advanced package controls. In a single-image ZIP it is named <image-name>_metadata.json. It records source dimensions, per-output file sizes, and available EXIF data for database import and downstream tooling.

Why the 8-width limit?

Each added width is resized and encoded per selected format. 8 widths × 3 formats = 24 encodes per image. In batch mode with 50 images that’s 1 200 encodes during ZIP export. The eight-width selection limit keeps per-image work predictable, while Batch streams completed variants into the ZIP instead of retaining the whole output set as blobs.

Recommended width sets

Output format settings

In the Advanced inspector, expand a format to configure its quality and codec options.

WebP

Powered by libwebp via @jsquash/webp. Best general-purpose choice.

Quality (0–100, default 70) - higher = better quality, larger file. The default is calibrated for balanced website delivery.

AVIF

Powered by libavif via @jsquash/avif. Smallest files, slower encode.

Quality (0–100, default 40) - the default is calibrated for balanced website delivery.

Progressive AVIF preview: A small thumbnail can appear on the comparison slider while an AVIF encode runs. The full result replaces it when encoding finishes.

The Advanced output-size advisory is calculated from the effective AVIF output area in megapixels, not from either dimension by itself and not from the original source area. Its device-memory-aware tiers begin at 12 MP on devices reporting up to 2 GB, 16 MP on devices reporting up to 4 GB or no memory value, and 20 MP on devices reporting more than 4 GB. The higher-risk tier begins at 18 MP, 24 MP, and 30 MP respectively. This is guidance rather than an encode block; the separate safe-upscaling policy still governs unsupported enlargement.

JPEG (MozJPEG)

Powered by MozJPEG via @jsquash/jpeg. Universal fallback.

Quality (0–100, default 74) - calibrated for balanced website delivery.

PNG (OxiPNG)

Powered by OxiPNG via @jsquash/png + @jsquash/oxipng. Lossless.

OxiPNG effort (1–6, default 3) - higher levels spend more time trying to reduce file size.

JPEG XL (JXL)

Powered by libjxl via @jsquash/jxl. Next-generation codec with excellent compression and lossless support.

Quality (0–100, default 72) - higher = better quality, larger file.

Browser compatibility and web delivery

IMPIB uses a bundled WebAssembly encoder, so it can create and download JXL files independently of the browser’s native image support. That does not mean every browser can display the exported file. Native JXL display support is still rolling out and can differ by browser version, platform, and configuration.

For website delivery, do not make JXL the only source unless every target browser has been verified. Use it as a <picture> source with an AVIF, WebP, JPEG, or PNG fallback, and test the browser versions your audience uses. The app’s ability to encode a JXL file is not a compatibility test for the destination browser.

Current implementation status should be checked against browser-vendor documentation before a deployment: WebKit’s Safari 17 announcement, Mozilla’s JPEG XL rollout notice, and Chrome release status.

JXL size limit

JXL output is limited to about 19 MP. The safe longest edge depends on the image’s aspect ratio.

The jxl_enc.wasm encoder has a 2 GB heap ceiling. IMPIB applies an empirical 19 MP output guard to avoid exhausting that memory during encoding. Resizing an oversized source below the guard can make JXL available.

When the configured JXL output dimensions exceed this limit:

• The jxl codec button is greyed out with a ! warning badge.
• Hovering the button shows the exact safe dimension for your image’s aspect ratio.
• The codec ⓘ info modal shows the limit and the recommended resize target.

To encode a large image to JXL, expand Output size in the Advanced inspector, choose Max edge, and enter a maximum side at or below the safe value shown in the warning. Then optimize again.

Standalone output size and resampling

Standalone-output controls are in Output size in the Advanced inspector, above the Optimize button.

Standalone output versus image set

The app produces two different kinds of output, and their dimensions are intentionally independent:

Resizing the standalone output does not resize or limit the source used to generate the image set. This avoids creating larger variants from an already reduced standalone file.

For example, with a 2400 × 1600 upload:

1. Set Standalone output size → Exact to 200 × 200.
2. Optimize to create the 200 × 200 standalone download.
3. In Output plan → Generate, select 320w, 640w, and 1200w.
4. Generate the set. Each variant is created directly from the 2400 × 1600 upload-not enlarged from the 200 × 200 standalone output.

Widths above the uploaded source width require Allow safe upscaling. Exact-size templates also compare their requirements with the uploaded source. Responsive enlargement is bounded by the browser safety policy; an unsafe width is skipped with its reason shown in the Batch Overview.

The Generate plan reports standalone-file and image-set-file counts separately. After generation, Download also keeps them in separate sections: Standalone output contains the optimized files, while Image set contains responsive variants and exact-size templates. Standalone files are never inserted into responsive srcset markup.

Global default and active job value

Settings → App → Standalone output sizing owns the global max-edge default. Its initial value is 1920px and Lanczos 3 is the default resampling method. Changing the longest-side value in the workspace customizes the active job only; it does not write back to the App global default.

The active job value persists when related images are uploaded, making it suitable for producing several consistent image sets. A fresh settings profile starts from the App global default.

Fit within box - how dimensions are calculated

The output size is determined by whichever axis is the tighter constraint:

scale = min(targetW / srcW, targetH / srcH, 1)
output = srcW × scale, srcH × scale

The 1 clamp means the image is never enlarged, even if the target box is bigger than the source.

Example: source 4032×3024 (4:3), target box 1920×1080 (16:9)

• W scale: 1920 / 4032 = 0.476
• H scale: 1080 / 3024 = 0.357 ← tighter
• Output: 1440 × 1080 - height hits the limit exactly, width stays under 1920

The output will always fit inside the box, but may be smaller than it on one axis when the source and target have different aspect ratios. If you need the longest edge to be exactly 1920, use Max edge with 1920 as the maximum instead.

Exact size - how cover crop works

The image is scaled until it fills the target box, then the overflow is trimmed symmetrically from the center:

scale = max(targetW / srcW, targetH / srcH)
1. Resize source to scaledW × scaledH
2. Crop scaledW × scaledH down to targetW × targetH from center

Example: source 4032×3024, target 1920×1080

• W scale: 1920 / 4032 = 0.476
• H scale: 1080 / 3024 = 0.357
• Takes the larger: scale = 0.476
• Resizes to 1920 × 1440, then crops 1920 × 1080 from the vertical center
• Output: exactly 1920 × 1080, subject kept centered

Open Crop after the first encode to manually reposition the crop region if the automatic center crop cuts off something important.

If a manual crop and Exact output use different aspect ratios, the app applies a second proportional cover crop instead of stretching the selected region. For example, a 3:2 crop sent to an Exact 500 × 500 output trims the sides to a square; it never squeezes the image.

Allow safe upscaling

Upscaling is off by default and shared by Standalone Max edge, Standalone Exact, responsive-width variants, and exact-size templates. Fit box never upscales.

The permission and the active state are separate. Allow safe upscaling is a persistent safety preference; the app never changes it automatically. Upscaling active is recalculated for every uploaded image and whenever its requested dimensions change. It becomes active only when the requested output exceeds the available source pixels, and turns off automatically after choosing a size that fits the source or resetting the standalone output size. A newly uploaded image is evaluated against its own dimensions.

When Max edge is larger than the uploaded image’s longest edge, the standalone output keeps its source dimensions unless Allow safe upscaling is enabled. With that preference enabled, it can be enlarged to the requested edge length within the app’s safety limits.

When Exact dimensions exceed the available source pixels, Optimize is disabled and reports the required enlargement factor. For example, 2.50× enlargement required means every output axis needs up to 2.5 times the available source resolution. Enable Allow safe upscaling in App Settings to proceed using the selected resampling algorithm.

Responsive variants use an additional memory guard because Batch can multiply one large resize by several formats and images. Targets up to 2× and 16 MP can use normal adaptive concurrency. Targets between 2–4× or 16–32 MP use one worker. Batch processes ordinary images through its parallel pool first, releases its standard worker memory, then handles only the images containing accepted heavy targets sequentially. Targets above 4× or 32 MP are skipped and shown in yellow with a safety explanation. A heavy or skipped width does not reduce concurrency for the remaining safe images. When safe upscaling is off, Batch keeps its standard worker policy and simply skips widths larger than their effective source.

JXL uses a stricter upscale rule because its WASM memory is additive with other selected codecs. When JXL is selected, any image requiring enlargement is moved to the sequential pass and its heavy worker is terminated after that image. JXL images that only generate native-size or smaller widths remain eligible for the normal parallel pass.

This is conventional resampling, not AI enhancement. It interpolates pixels but cannot reconstruct missing detail.

Resampling methods

Use the compact Resampling selector inside Standalone output size to override the App Settings default for the current job.

Adjustments

In single-image Advanced mode, open Settings → /adjustments to apply tonal corrections before encoding. A pending Batch item also has an Adjust tool in its preview for per-image edits.

All adjustments are applied in the worker in a fixed order: noise reduction → brightness/contrast/saturation/warmth (fused single pass) → sharpness.

Live preview: Moving any slider fires a fast WebP q=85 preview encode (~120 ms debounce). The comparison slider and zoom compare both update without a full re-encode.

Re-encode to finalise: The live preview is NOT the final output. Click [re-optimize] to bake the adjustments into the encoded file at your chosen codec and quality.

[reset all] resets every adjustment to 0. Adjustments also reset automatically when a new image is loaded - they are per-image, not global.

Adjustments are image-specific. Recipes control reusable codec, quality, image-size, variant, naming, and metadata settings; they do not apply the previous image’s adjustment state.

Zoom compare

After encoding, click [zoom] in the toolbar to open a side-by-side split view.

• Both panels share zoom and pan state - they always show the identical region.
• Scroll or pinch to zoom (up to 8× on the full layout and 3× on the compact layout), then drag to pan.
• The format switcher lets you compare formats that have already been generated for the active image without encoding them again.
• When adjustments are pending (sliders moved but not yet re-encoded), opening zoom compare immediately shows the adjusted fast preview. The right panel label reads “Adjusted (preview)” to distinguish it from a final encode. Click [re-optimize] to bake the adjustments before zooming if you need pixel-accurate comparison.
• Press Esc or ← Back to slider to return.

Crop

1. Click Crop in the workspace tools.
2. Drag handles to select a region. Use aspect ratio pills (Free, 1:1, 3:2, 4:3, 16:9…) to lock the ratio.
3. Click Apply crop to re-encode at the cropped dimensions.
4. Use Reset applied crop to restore the full source while preserving rotation and flip edits.

Crop state is preserved per-image session. Re-opening crop after applying restores the exact selection and ratio lock from the previous session. The state is cleared only when a new image is loaded.

Crop state and info

Crop info is visible in Inspect under the CROP row. It shows the applied pixel region as width×height @ x,y.

Crop is not stored in presets. Presets capture codec, quality, and resize settings that apply to any image. A crop is a pixel selection tied to the exact dimensions of one specific image and would produce meaningless or broken results applied to a different image.

Metadata policy

In Single Advanced, open Delivery below the output-size controls. Batch exposes the same policy in its shared Inspector. The setting affects downloaded files; source metadata shown in Inspect remains available during the current session.

JPEG and WebP currently embed the selected EXIF metadata in the downloaded image. AVIF, JXL, and PNG downloads are currently written without EXIF; choosing a keep policy does not change that limitation. The formats themselves can carry metadata, but native container writing is not implemented for those codecs in the current app. The optional metadata package report can preserve a structured description even when the selected codec cannot embed EXIF.

Metadata report in image-set ZIPs

An optional report can be included in image-set ZIPs through the global Export settings or the active Advanced package controls. A single-image ZIP names it <image-name>_metadata.json; Batch names it metadata.json inside each source folder. It records source information, per-output sizes, and available EXIF data for downstream tooling. The following is a shortened single-image example; actual reports include additional fields.

{
	"_generatedAt": "2026-05-17T10:00:00.000Z",
	"_metadataPolicy": "strip_gps",
	"_source": { "width": 4032, "height": 3024, "size": 3145728, "format": "image/jpeg" },
	"_variants": [
		{
			"width": 640,
			"formats": [
				{ "format": "webp", "size": 18432 },
				{ "format": "avif", "size": 12288 }
			]
		}
	],
	"exif": { "camera": "Apple iPhone 15 Pro", "iso": 50, "aperture": 1.78 }
}

The exif key is absent when policy is strip_all or the source has no EXIF.

Recipes

Factory recipes are available from App Settings → Startup:

Create, import, edit, and apply reusable configurations from App Settings → Recipes. Applying a recipe restores its codec, quality, image-size, variant, naming, and metadata configuration. Image-specific crop and adjustment state is not applied to another source.

The selected recipe is restored when a new single image is loaded. Manual edits and Analysis advice for one image therefore do not carry into the next image unless you save them in a recipe. In Standard, the selected compression preset is applied on top of that restored recipe.

Performance panel

Click the gauge icon in the image-set or Batch panel to open the performance summary in the workspace. Use the gauge icon on that summary to expand or collapse its details. The details refresh every second while open.

Single image

The summary shows output size, percentage saved, and encode time. Its details show the primary output state and sizes, encode time, variant progress when an image set is being generated, and the current worker workload and memory-safe limit. A timer footer shows primary, variant, and total processing time after work starts. An Active resources count appears only when there are tracked blob URLs.

Batch

Once images have been added, the summary shows image progress, saved percentage, and output size. The expanded details include:

The timer footer shows primary, variant, and total processing time once a run has started. Retained is the app’s tracked retained blob data, not total browser or JavaScript heap use. Throughput is an estimate based on completed encodes and worker concurrency.

Theme

Use the moon/sun theme button in the top-right corner to toggle between dark and light themes. Your preference is saved locally and applied on the next load with no flash.

Limits & performance notes

Performance tips:

• AVIF speed below 4 can substantially increase encode time. Use a higher speed for interactive work.
• JXL effort above 8 can take tens of seconds on large images. AVIF and JXL both use large WASM heaps; selecting both, adding responsive widths, or running target-size search multiplies the work. Single-image and Batch schedulers reduce parallelism automatically rather than assuming every device has the same memory or CPU capacity.
• WebP method 6 + 10 passes is the slowest WebP config. Use method 4 + 1 pass for previews.
• PNG OxiPNG level 6 is slow on large images. Level 3 is a good default for most use cases.
• Batch mode uses a hardware-, codec-, and resolution-aware worker limit. An 8-core machine may use all 8 workers for WebP/JPEG, while AVIF, JXL, additional formats, and high-resolution images reduce concurrency to protect memory.
• Auto-generate on upload (Settings → App → Automation) encodes every selected single-image target after analysis. Disable it when you want to configure the job before encoding.
• Run quality search after upload (Settings → App → Automation) performs the more expensive SSIM search automatically. Pixel analysis still runs for every image.

Connection loss while encoding

Images are processed locally, but the browser may download a codec worker or WASM module only when that format is used for the first time. If a hotspot disconnects, cellular tethering is restricted, or the connection changes before that download finishes, the current encode stops safely and the app shows Encoding resources could not be loaded. The source image and completed outputs remain local.

Restore the connection, then use Optimize again in Standard or Advanced, the Retry action on a failed Batch image, or rerun Quality Search. Failed codec initialization is cleared before retrying, so the browser makes a fresh resource request instead of retaining the earlier network failure.

This recovery handles errors reported to the page. If the operating system terminates the whole browser tab because of memory pressure, no web app can display an in-page error; reopen the page and use smaller outputs or fewer simultaneous Batch files.

Parallel batch processing

IMPIB runs image encoding in your browser. Each AVIF encode and OxiPNG optimisation uses a single-threaded WASM build, but Batch can process different images concurrently in separate workers. The hosting service delivers the app and its assets; it does not receive your images or perform the encoding. Cross-origin isolation headers may be sent by the host, but they do not switch these codecs to multi-threaded builds in the current app.

Dynamic batch limit

Batch capacity is not a fixed public promise. When the browser exposes approximate device memory, IMPIB computes a safe working capacity from that value:

Processed batch items retain their source files and output blobs. The amount depends on the actual file sizes. Each active encode worker also holds decoded pixel data during encoding (at least ~4 × W × H bytes for an RGBA image), so the app limits batch size and worker concurrency based on available device information.

Safari, Firefox, and other browsers that do not expose device memory use a fixed conservative 100-image tier. CPU core count does not increase this capacity.

Total batch memory budget

The item count limit alone is not enough to prevent memory exhaustion - a batch of 20 × 50 MB images has the same item count as 20 × 50 KB thumbnails but carries 1 000× more raw data. IMPIB therefore enforces a second, independent total byte budget across all files currently in the batch.

The budget is computed at startup from the same approximate navigator.deviceMemory signal as the item count limit. When that signal is unavailable, the fixed budget is 750 MB:

These tiered budgets leave room for:

• Decoded pixel buffers held inside active encode workers (~4 × W × H bytes each)
• Encoded output blobs and display-original WebPs retained after each encode
• Browser and OS overhead

How rejection works: When files are dropped, IMPIB measures the running total of raw file bytes already in the batch. Each new file is accepted or rejected based on whether adding it would exceed the budget. Files that fit are accepted. Oversized and over-budget files are rejected before Batch creates an item, object URL, metadata state, or worker task, so their File objects are not retained by the app. A warning reports the device’s item, total-byte, and per-image limits. Files that were already queued or processing are never affected.

This check happens in file-drop order, so if you drop a mix of large and small files simultaneously, as many files as fit within the budget are accepted and the remainder are not added. Removing an accepted item immediately frees its raw-file bytes from the running budget.

Streamed responsive workload

Batch does not impose a separate total responsive-file limit. Responsive files are generated through bounded worker lanes and written into the ZIP as they complete, rather than retaining every generated blob until the end. A larger images × widths × formats total therefore increases processing time and archive size without growing retained output blobs in proportion to the whole job.

Memory protection instead applies where data is retained: source image count, individual and combined source bytes, decoded dimensions, active worker concurrency, and a transactional per-image archive buffer. Safari, Firefox, and other browsers without memory telemetry keep the fixed 100-image and 750 MB source tier; processor count is not treated as a substitute for memory information.

Resolution-aware concurrency (pro photographer support)

File size is a poor proxy for memory pressure - a 3 MB JPEG and a 30 MB JPEG from the same camera can decode to identical pixel buffers. What matters is resolution.

The worker pool adjusts how many images encode simultaneously based on each source image’s pixel count:

IMPIB reads dimensions before starting an encode worker. If the next image would exceed the remaining worker budget, it waits in the queue. A single image can always start when no others are running.

The 50 MB per-file hard limit accommodates large supported JPEG, PNG, WebP, and AVIF sources. The total batch memory budget provides a separate, cumulative cap that prevents a batch of many large files from exhausting device memory even if each individual file passes the per-file check.

WASM error auto-retry

An encode worker may report a WASM trap such as Unreachable code should not be executed, or an out-of-memory or allocation error. These errors can occur during a demanding Batch job and do not by themselves prove that the source image is invalid.

The batch optimizer detects this error (along with OOM and allocation failures) and automatically:

1. Terminates the corrupted worker
2. Flushes all pre-warmed workers from the pool
3. Waits 800 ms for garbage collection
4. Re-queues the failed item with a fresh worker

Each item is retried at most once automatically. If the retry also fails, the item is marked as failed with an error message. The ↺ Retry button starts a fresh attempt; reduce output sizes or Batch concurrency if memory pressure continues.

Format-switch GC pause: When re-encoding all items (e.g. switching from WebP to AVIF), the batch optimizer terminates all active workers and then waits 500 ms before launching new ones. This gives the browser’s garbage collector time to reclaim WASM linear memory from the previous codec’s workers. Without this pause, the old and new WASM instances coexist briefly and can exceed the browser’s memory budget, causing transient OOM errors on a few images.

Browser support

Modern evergreen browsers with support for:

• WebAssembly
• ES module Web Workers
• OffscreenCanvas (used for crop operations inside the worker)

navigator.hardwareConcurrency helps size the worker pool when available; IMPIB uses a fallback when it is not.

Encoding runs in the browser, so codec speed and available memory depend on the browser and device.

AVIF and PNG worker behavior

IMPIB currently selects single-threaded WASM builds for AVIF encoding and OxiPNG optimisation on every browser. Cross-Origin Isolation headers from the hosting service do not change this. Batch can use multiple CPU cores by processing separate images in parallel workers; a single image encode does not use all cores.