Converting HEIC and HEIF Assets for the Web

HEIC and HEIF files often appear in web projects because modern phones and cameras can create them by default. They are efficient capture formats, but they are not always convenient for website publishing, CMS uploads, design handoff, or customer-facing pages. Many teams still need to convert them to web-friendly outputs such as WebP, JPEG, or PNG depending on the image and platform.

The right workflow is not "convert everything immediately." It is to preserve the source, choose the web destination, convert a sample, and review quality before publishing.

"HEIC is not web friendly, convert it to WebP" skips the publishing decisions that matter: which images are approved, whether they need resizing first, which output format the placement accepts, what metadata can be public, and whether the converted result still looks right on the page.

Keep the HEIC or HEIF Original#

Treat HEIC and HEIF files as source material. Do not overwrite them during conversion. They may contain the highest-quality version available, and they may be needed later for new crops, print requests, or another export format.

Use a simple structure:

phone-photos/
  originals-heic/
  working/
  web-output/

The original folder stays unchanged. The working folder can contain resized or selected files. The web output folder contains approved files for upload or deployment.

For GetWebP CLI specifically, originals are not modified or deleted during conversion. The CLI commands reference documents separate output directories with --output, recursive scanning with --recursive, and HEIC/HEIF as supported input formats for WebP or AVIF output.

Decide the Destination First#

Before converting, decide where the image will be used:

• website hero
• product gallery
• blog article image
• staff profile
• support documentation
• social preview
• email header

The destination determines size, crop, format, and review standard. A staff photo for a profile card does not need the same dimensions as a portfolio hero. A social platform may have different format rules than your website.

Use a small planning table:

Resize Before Encoding#

Phone images can be much larger than the website needs. Resize to the largest practical display size before encoding. This reduces waste and makes the output easier to review.

For example, if a blog image is displayed at 1200 pixels wide, a 4000-pixel source can usually be resized before conversion. Keep the original HEIC or HEIF for future use, but do not serve the full capture size when the layout does not need it.

GetWebP CLI is the conversion step, not the art-direction step. If the image needs cropping, rotation, or multiple responsive widths, do that in the image workflow before conversion or in the site's image pipeline. Then run conversion against the approved working folder:

phone-photos/
  originals-heic/
  working-resized/
  web-output/
  reports/

Convert to WebP for Website Delivery#

GetWebP CLI supports HEIC and HEIF as input formats, so a local conversion command can be straightforward:

getwebp ./phone-photos/working-resized \
  -o ./phone-photos/web-output \
  --recursive \
  --quality 82 \
  --json > ./phone-photos/reports/heic-webp.ndjson

The output should be reviewed before upload. HEIC sources can contain detailed photos, portraits, or low-light images, and each category may react differently to compression.

If the image contains transparency or is a screenshot-like capture, compare WebP with PNG or another suitable format instead of assuming one output setting fits every file.

If the site is testing AVIF, run that as a separate output set:

getwebp ./phone-photos/working-resized \
  -o ./phone-photos/avif-output \
  --recursive \
  --format avif \
  --quality 55 \
  --json > ./phone-photos/reports/heic-avif.ndjson

WebP auto quality and AVIF fixed quality are not the same thing. The CLI reference documents that auto quality is WebP-only and AVIF uses fixed quality by default. Keep the quality and qualityMode fields in the report so the comparison remains honest.

Use the Report as Evidence#

The JSON output reference documents per-file results such as outputPath, originalSize, newSize, savedRatio, quality, qualityMode, and status.

After conversion, extract a review table:

jq -r '
  select(.type == "convert.completed")
  | .data.results[]
  | [.status, .file, (.outputPath // ""), (.originalSize // ""), (.newSize // ""), (.savedRatio // ""), (.quality // ""), (.qualityMode // ""), (.error // "")]
  | @tsv
' ./phone-photos/reports/heic-webp.ndjson

This report helps catch:

Review Color and Detail#

Phone-origin images can expose quality issues in subtle ways. Check:

• faces and skin tones
• indoor lighting and shadows
• sky gradients
• fabric and hair detail
• product texture
• small text in photographed signs or packaging
• dark areas with noise

Open the output in the page where it will be used. A photo that looks acceptable in a file viewer can feel too soft as a wide hero or too compressed in a gallery zoom view.

Also check orientation and crop. Phone-origin images can carry orientation expectations from the capture workflow, and a wrong rotation or crop is a publishing defect even when the codec output is technically valid.

Watch Metadata and Privacy#

HEIC and HEIF files may include metadata such as capture time, device information, and sometimes location data. Before publishing, decide which metadata belongs in public outputs.

A conservative workflow keeps full metadata in the private original and publishes an optimized output only after metadata policy has been checked. Do not assume every tool preserves metadata or strips it in the way your policy requires. Verify the public output before upload.

This is especially important for staff photos, office photos, events, homes, unreleased products, and customer images. The GetWebP security overview explains the local conversion boundary: image-processing data stays local to the conversion environment, while license and account traffic are separate control-plane activity. That privacy boundary is useful, but it does not replace your responsibility to review what metadata ends up in a public file.

Keep Fallback Needs in Mind#

If your website already serves WebP with a JPEG fallback, generate the required fallback files from the same approved source. If your CMS or email platform does not accept WebP for a specific placement, export the format that placement requires.

MDN's image file type guide gives context for common web image formats, and Google's WebP documentation explains the WebP format used for many optimized website outputs.

For a conservative website rollout:

If the page uses responsive images, verify every required size. A successful single-file conversion does not prove that the 480w, 960w, and 1400w variants all exist.

Be Careful With Watch Mode#

HEIC and AVIF sources can be memory-heavy. In GetWebP watch mode, the CLI has safeguards for these sources, including a size pre-check and sequential processing after HEIC/AVIF is detected in a session. That is useful for long-running automation, but it is not a reason to point a watcher at a broad phone-photo dump.

For HEIC and HEIF publishing work, a bounded batch is usually clearer:

1. select approved originals
2. resize or crop into a working folder
3. convert that working folder
4. inspect the structured report
5. review outputs in page context
6. publish only the approved files

Document the Conversion Rule#

Write a short rule for future HEIC and HEIF files:

Copy phone originals to originals-heic, select approved images, resize or crop
into working-resized, convert to WebP or AVIF into a separate output folder,
keep the NDJSON report, review in the page, verify metadata policy, and keep
originals archived.

That rule saves time when more phone photos arrive later.

HEIC and HEIF files are not a problem by themselves. They just need a publishing workflow. Preserve the source, resize for the destination, convert locally, review carefully, and publish only the outputs that fit the web context.